You are on page 1of 319

IEEE Standard for Standard

SystemC

Language Reference
Manual
Sponsored by the
Design Automation Standards Committee
IEEE
3 Park Avenue
New York, NY 10016-5997
USA
9 January 2012
IEEE Computer Society
IEEE Std 1666"-2011
(Revision of
IEEE Std 1666-2005)
IEEE Std 1666

-2011
(Revision of
IEEE Std 1666-2005)
IEEE Standard for Standard
SystemC

Language Reference
Manual
Sponsor
Design Automation Standards Committee
of the
IEEE Computer Society
Approved 10 September 2011
IEEE-SA Standards Board
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
Copyright 2012 by the Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 9 January 2012. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
Engineers, Incorporated.
SystemC is a registered trademark in the U.S. Patent & Trademark Office, owned by the Accellera Systems Initiative.
Print: ISBN978-0-7381-6801-2 STD97162
PDF: ISBN978-0-7381-6802-9 STDPD97162
IEEE prohibits discrimination, harassment, and bullying. For more information, visit http://www.ieee.org/web/aboutus/
whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.
Grateful acknowledgment is made to the Open SystemC Initiative (OSCI) for the permission to use
the following source material:
OSCI TLM Language Reference Manual Version 2.0.1
Note that a merger of OSCI and Accellera, announced on 5 December 2011, created a new
organization, Accellera Systems Initiative.
Abstract: SystemC

is defined in this standard. SystemC is an ANSI standard C++ class library


for system and hardware design for use by designers and architects who need to address complex
systems that are a hybrid between hardware and software. This standard provides a precise and
complete definition of the SystemC class library so that a SystemC implementation can be
developed with reference to this standard alone. The primary audiences for this standard are the
implementors of the SystemC class library, the implementors of tools supporting the class library,
and the users of the class library.
Keywords: C++, computer languages, digital systems, discrete event simulation, electronic
design automation, electronic system level, electronic systems, embedded software, fixed-point,
hardware description language, hardware design, hardware verification, IEEE 1666, SystemC,
system modeling, system-on-chip, transaction level
I EEE Standards documents are devel oped wi thi n the I EEE Societi es and the Standards Coordi nati ng
Commi ttees of the IEEE Standards Associati on (I EEE-SA) Standards Board. The I EEE devel ops i ts standards
through a consensus devel opment process, approved by the Ameri can Nati onal Standards I nstitute, whi ch
bri ngs together vol unteers representing vari ed vi ewpoints and i nterests to achi eve the f i nal product. Vol unteers
are not necessari l y members of the I nsti tute and serve wi thout compensati on. Whi l e the I EEE admi ni sters the
process and establi shes rul es to promote fai rness i n the consensus devel opment process, the I EEE does not
i ndependentl y eval uate, test, or veri f y the accuracy of any of the i nf ormati on contai ned i n i ts standards.
Use of an I EEE Standard i s whol l y vol untary. The I EEE di sclai ms l i abi l i ty f or any personal i nj ury, property or
other damage, of any nature whatsoever, whether speci al , i ndi rect, consequenti al , or compensatory, di rectl y or
i ndirectl y resul ti ng f rom the publ i cati on, use of , or rel i ance upon thi s, or any other I EEE Standard document.
TheI EEE does not warrant or represent the accuracy or content of the materi al contai ned herei n, and expressl y
di scl ai ms any express or i mpl i ed warranty, incl udi ng any i mpl i ed warranty of merchantabi l i ty or f i tness f or a
speci f i c purpose, or that the use of the materi al contai ned herei n i s f ree f rom patent i nf ri ngement. I EEE
Standards documents are supplied ASI S.
The exi stence of an I EEE Standard does not i mpl y that there are no other ways to produce, test, measure,
purchase, market, or provi de other goods and services rel ated to the scope of the I EEE Standard. Furthermore,
the vi ewpoi nt expressed at the ti me a standard i s approved and i ssued i s subj ect to change brought about
through developments i n the state of the art and comments recei ved f rom users of the standard. Every I EEE
Standard i s subj ected to revi ew at l east every f i ve years f or revi si on or reaf f i rmati on. When a document i s
more than f i ve years old and has not been reaf f i rmed, i t i s reasonabl e to concl ude that i ts contents, al though
sti l l of some val ue, do not whol l y ref lect the present state of the art. Users are cauti oned to check to determi ne
that they have the l atest edi ti on of any I EEE Standard.
I n publ i shi ng and making thi s document avai l abl e, the I EEE i s not suggesti ng or renderi ng prof essi onal or
other servi ces f or, or on behal f of , any person or enti ty. Nor i s the I EEE undertaki ng to perf orm any duty owed
by any other person or enti ty to another. Any person uti l i zi ng thi s, and any other I EEE Standards document,
shoul d rely upon the advice of a competent professi onal i n determi ni ng the exerci se of reasonabl e care i n any
gi ven ci rcumstances.
I nterpretati ons: Occasi onal l y questi ons may ari se regardi ng the meaning of porti ons of standards as they rel ate
to speci f i c appl i cati ons. When the need f or i nterpretati ons i s brought to the attenti on of I EEE, the I nsti tute wi l l
i ni tiate acti on to prepare appropri ate responses. Si nce I EEE Standards represent a consensus of concerned
i nterests, i t i s important to ensure that any i nterpretation has al so recei ved the concurrence of a bal ance of
i nterests. For this reason, I EEE and the members of i ts soci eti es and Standards Coordi nati ng Commi ttees are
not abl e to provi de an i nstant response to i nterpretati on requests except i n those cases where the matter has
previ ously recei ved f ormal considerati on. At l ectures, symposi a, semi nars, or educati onal courses, an
i ndivi dual presenti ng i nf ormati on on I EEE standards shal l make i t cl ear that hi s or her vi ews shoul d be
consi dered the personal vi ews of that i ndi vi dual rather than the f ormal posi ti on, expl anati on, or interpretati on
of the I EEE. Comments for revi si on of I EEE Standards are wel come f rom any i nterested party, regardl ess of
membershi p af f i l i ation wi th IEEE. Suggesti ons f or changes i n documents shoul d be i n the f orm of a proposed
change of text, together wi th appropri ate supporti ng comments.
Comments on standards and requests f or i nterpretati ons shoul d be addressed to:
Secretary, I EEE-SA Standards Board
445 Hoes Lane
Pi scataway, NJ 08854-4141
USA
Authori zati on to photocopy porti ons of any i ndivi dual standard f or i nternal or personal use i s granted by the
I nsti tute of El ectri cal and El ectroni cs Engi neers, Inc., provi ded that the appropri ate f ee i s pai d to Copyri ght
Cl earance Center. To arrange f or payment of l i censing f ee, pl ease contact Copyri ght Clearance Center,
Customer Servi ce, 222 Rosewood Dri ve, Danvers, MA 01923 USA; +1 978 750 8400. Permi ssi on to
photocopy porti ons of any i ndi vi dual standard for educati onal cl assroom use can al so be obtai ned through the
Copyri ght Cl earance Center.
iv
Copyright 2012 IEEE. All rights reserved.
Introduction
This document def ines SystemC, which is a C++ cl ass l ibrary.
As the electroni cs i ndustry bui lds more complex systems i nvol vi ng large numbers of components including
sof tware, there i s an i ncreasing need for a model ing language that can manage the complexity and size of
these systems. SystemC provi des a mechanism for managing this compl exi ty with i ts facil ity f or model ing
hardware and sof tware together at multipl e level s of abstraction. This capabil ity is not avail abl e in
tradi ti onal hardware descripti on l anguages.
Stakeholders in SystemC i ncl ude Electroni c Design Automation (EDA) companies who impl ement
SystemC cl ass l ibraries and tool s, i ntegrated circui t (IC) suppl iers who extend those cl ass l ibraries and use
SystemC to model their i ntell ectual property, and end users who use SystemC to model their systems.
Before the publi cation of thi s standard, SystemC was defi ned by an open-source, proof -of-concept C++
li brary, al so known as the reference si mul ator, avail abl e from the Accel lera Systems I ni ti ati ve. I n the event
of discrepanci es between the behavior of the reference simul ator and statements made in this standard, thi s
standard shal l be taken to be defi nitive.
This standard is not intended to serve as a users guide or to provi de an introduction to SystemC. Readers
requiring a SystemC tutorial or inf ormati on on the i ntended use of SystemC shoul d consult the Accell era
Systems I ni ti ative Web site (www.accel lera.org) to l ocate the many books and trai ning classes avai lable.
Note that the Open Systems I nitiati ve (OSCI) announced i n December 2011 i ts merger with Accel lera to
form the Accellera Systems Initiative. The name of the new organizati on has been used throughout thi s
document instead of the name Open SystemC Imitative or the acronym OSCI. The exceptions are in
statements that refer to previous OSCI actions, and standards such as OSCI TLM-2.0.1, whose names
have not been changed.
Notice to users
Laws and regulations
Users of these documents should consult al l appl icabl e laws and regul ations. Compl iance wi th the
provisions of thi s standard does not i mply compliance to any appl icabl e regulatory requi rements.
I mplementers of the standard are responsible f or observing or ref erri ng to the appli cabl e regul atory
requirements. I EEE does not, by the publi cati on of its standards, intend to urge action that is not i n
compliance wi th appl icabl e laws, and these documents may not be construed as doing so.
Copyrights
This document is copyri ghted by the I EEE. I t i s made avai lable for a wi de variety of both publ ic and pri vate
uses. These i ncl ude both use, by reference, in laws and regulati ons, and use in private sel f-regulati on,
standardi zation, and the promoti on of engi neeri ng practices and methods. By maki ng this document
avai lable for use and adopti on by publi c authori ti es and private users, the IEEE does not wai ve any rights in
copyright to thi s document.
This i ntroducti on i s not part of I EEE Std 1666-2011, I EEE Standard f or Standard SystemC

Language Reference
Manual .
v
Copyright 2012 IEEE. All rights reserved.
Updating of IEEE documents
Users of IEEE standards shoul d be aware that these documents may be superseded at any time by
the i ssuance of new editions or may be amended from time to time through the issuance of
amendments, corrigenda, or errata. An offi ci al I EEE document at any point in time consi sts of the
current edi tion of the document together with any amendments, corrigenda, or errata then i n eff ect.
I n order to determi ne whether a gi ven document is the current edition and whether it has been
amended through the issuance of amendments, corrigenda, or errata, visit the I EEE Standards
Associati on websi te at http://ieeexplore.i eee.org/xpl/standards.j sp, or contact the I EEE at the address
li sted previ ously.
For more informati on about the I EEE Standards Associati on or the I EEE standards development process,
visit the IEEE-SA website at http://standards.ieee.org.
Errata
Errata, i f any, f or this and al l other standards can be accessed at the f ol lowi ng URL: http://
standards.ieee.org/fi ndstds/errata/i ndex.html. Users are encouraged to check thi s URL f or errata
periodicall y.
Interpretations
Current i nterpretations can be accessed at the foll owing URL: http://standards.ieee.org/fi ndstds/
interps/index.html.
Patents
Attenti on is call ed to the possibil ity that i mplementati on of thi s standard may requi re use of subject matter
covered by patent rights. By publ icati on of thi s standard, no posi ti on is taken with respect to the exi stence or
val idi ty of any patent ri ghts i n connection therewith. The IEEE shall not be responsibl e f or identif ying
patents or patent appl icati ons for whi ch a l icense may be requi red to i mplement an I EEE standard or for
conducti ng inquiries i nto the legal val idity or scope of those patents that are brought to its attenti on.
vi
Copyright 2012 IEEE. All rights reserved.
Participants
This entity-based standard was created under the leadershi p of the fol lowi ng i ndi vi dual s:
Stan Krolikoski, Chai r
JeromeCornet, Vi ce Chai r
John Aynsley, Techni cal Lead and Author
David Long, Co-Author (SystemC Data Types)
DennisBrophy, Secretar y
SofieVandeputte, Typogr aphi cal Edi tor
At the time this enti ty-based standard was completed, the LRM Worki ng Group had the f oll owing
membership:
The f ol lowi ng members of the enti ty-based bal loting commi ttee voted on this standard. Bal loti ng enti ti es
may have voted for approval, disapproval, or abstention.
The worki ng group gratef ul ly acknowledges the contributi ons of the f ol lowi ng participants:
Accel l era Organi zati on
Cadence Design Systems
Freescal e Semi conductors
I ntel Corporati on
JEITA
Mentor Graphi cs
NXP Semi conductors
OSCI
STARC
STMi croel ectroni cs
Synopsys
Texas I nstruments
Accel l era Organi zati on
Cadence Desi gn Systems
I ntel Corporati on
JEI TA
Mentor Graphi cs
NXP Semi conductors
OSCI
Qual comm Incorporated
SGCC
STARC
STMi croel ectroni cs
Synopsys
Texas I nstruments
John Aynsl ey
Bi shnupri ya Bhattacharya
Davi d C. Bl ack
Jerome Cornet
Al an Fitch
Mark Gl asser
Puneet Goel
Andy Goodrich
Phil i pp A. Hartmann
Hi roshi I mai
Marti n Janssen
Tor Jeremiassen
Davi d Long
Mi chael McNamara
Mi ke Meredi th
Eric E. Roesl er
Stuart Swan
Bart Vanthournout
Yossi Vel l er
Kaz Yoshi naga
vii
Copyright 2012 IEEE. All rights reserved.
When the I EEE-SA Standards Board approved this standard on 10 September 2011, it had the f oll owing
membership:
Richard H. Hulett, Chai r
John Kulick, Vi ce Chai r
Robert Grow, Past Chai r
Judith Gorman, Secr etary
* Member Emeri tus
Al so included are the fol lowing nonvoti ng I EEE-SA Standards Board l iaisons:
Satish K. Aggarwal, NRC Repr esentati ve
Ri chard DeBlasi o, DOE Repr esentati ve
Al an H. Cookson, NI ST Repr esentati ve
Mi chel l e D. Turner
I EEE Standar ds Pr ogram Manager , Document Devel opment
Joan Wool ery
I EEE Standar ds Pr ogr am Manager , Techni cal Pr ogr amDevel opment
Masayuki Ariyoshi
Wi ll i am Bartl ey
Ted Burse
Cl i nt Chapl i n
Wael Di ab
Jean-Phi l i ppe Faure
Al ex Gel man
Paul Houz
Ji m Hughes
Joseph L. Koepf i nger*
Davi d Law
Thomas Lee
Hung Li ng
Ol eg Logvi nov
Ted Ol sen
Gary Robi nson
Jon Rosdahl
Sam Sci acca
Mi ke Seavey
Curti s Si l l er
Phil Wi nston
Howard Wolf man
Don Wri ght
vii i
Copyright 2012 IEEE. All rights reserved.
Contents
1. Overview.............................................................................................................................................. 1
1.1 Scope............................................................................................................................................ 1
1.2 Purpose......................................................................................................................................... 1
1.3 Subsets......................................................................................................................................... 2
1.4 Relationshi p withC++................................................................................................................. 2
1.5 Gui dancefor readers.................................................................................................................... 2
2. Normativereferences........................................................................................................................... 4
3. Termi nol ogy and conventi ons used i n this standard............................................................................ 5
3.1 Terminology................................................................................................................................. 5
3.1.1 Shal l, shoul d, may, can.................................................................................................... 5
3.1.2 Implementati on, appl icati on............................................................................................ 5
3.1.3 Call , call ed from, deri ved from........................................................................................ 5
3.1.4 Specifi ctechnical terms................................................................................................... 5
3.2 Syntacti cal conventions............................................................................................................... 7
3.2.1 Implementati on-defined................................................................................................... 7
3.2.2 Di sabled........................................................................................................................... 7
3.2.3 Ell ipsis (...)....................................................................................................................... 7
3.2.4 Classnames...................................................................................................................... 7
3.2.5 Embolded text .................................................................................................................. 8
3.3 Semanti c conventi ons.................................................................................................................. 8
3.3.1 Classdefi ni ti ons and theinheri tancehierarchy ............................................................... 8
3.3.2 Functi ondefi niti onsand side-effects............................................................................... 8
3.3.3 Functionswhosereturn typeis areferenceor apointer .................................................. 8
3.3.4 Namespaces and internal nami ng.................................................................................. 10
3.3.5 Non-compliant applicati ons and errors.......................................................................... 11
3.4 Notes and exampl es................................................................................................................... 11
4. Elaborati onand si mulati on semanti cs............................................................................................... 12
4.1 El aboration................................................................................................................................. 12
4.1.1 Instanti ati on ................................................................................................................... 12
4.1.2 Process macros............................................................................................................... 14
4.1.3 Port bi nding and export binding.................................................................................... 14
4.1.4 Setti ng thetimeresolution............................................................................................. 15
4.2 Si mulati on.................................................................................................................................. 15
4.2.1 Thescheduli ngalgorithm.............................................................................................. 16
4.2.2 Ini ti al ization, cycles, and pauses in thescheduling algori thm....................................... 19
4.3 Running el aboration and si mulati on.......................................................................................... 20
4.3.1 Function declarations..................................................................................................... 20
4.3.2 Function sc_el ab_and_sim............................................................................................. 20
4.3.3 Functionssc_argc andsc_argv ...................................................................................... 21
4.3.4 Runni ng under appli cation control usi ngfunctions sc_main and sc_start..................... 21
4.3.5 Runni ngunder control of thekernel .............................................................................. 23
4.4 El aboration and si mulation call backs........................................................................................ 23
4.4.1 before_end_of_elaborati on............................................................................................ 24
4.4.2 end_of_elaboration........................................................................................................ 25
4.4.3 start_of_si mulation........................................................................................................ 26
ix
Copyright 2012 IEEE. All rights reserved.
4.4.4 end_of_simul ati on ......................................................................................................... 27
4.5 Other functi ons rel ated to the scheduler .................................................................................... 27
4.5.1 Function declarations..................................................................................................... 27
4.5.2 Function sc_pause.......................................................................................................... 28
4.5.3 Functi on sc_stop, sc_set_stop_mode, and sc_get_stop_mode ...................................... 29
4.5.4 Function sc_ti me_stamp ................................................................................................ 30
4.5.5 Function sc_del ta_count ................................................................................................ 31
4.5.6 Function sc_is_running.................................................................................................. 31
4.5.7 Functi ons to detect pending activity .............................................................................. 31
4.5.8 Function sc_get_status................................................................................................... 32
5. Core language class defi ni ti ons......................................................................................................... 35
5.1 Cl ass header fi les....................................................................................................................... 35
5.1.1 #include "systemc"......................................................................................................... 35
5.1.2 #include "systemc.h" ...................................................................................................... 35
5.2 sc_modul e.................................................................................................................................. 37
5.2.1 Descripti on..................................................................................................................... 37
5.2.2 Class defi nition .............................................................................................................. 37
5.2.3 Constraints on usage...................................................................................................... 39
5.2.4 kind ................................................................................................................................ 39
5.2.5 SC_MODULE ............................................................................................................... 40
5.2.6 Constructors................................................................................................................... 40
5.2.7 SC_CTOR...................................................................................................................... 40
5.2.8 SC_HAS_PROCESS..................................................................................................... 41
5.2.9 SC_METHOD, SC_THREAD, SC_CTHREAD........................................................... 42
5.2.10 Method process.............................................................................................................. 43
5.2.11 Thread and cl ocked thread processes............................................................................. 43
5.2.12 Clocked thread processes............................................................................................... 44
5.2.13 reset_si gnal _i s and async_reset_si gnal _is..................................................................... 46
5.2.14 sensitive ......................................................................................................................... 48
5.2.15 dont_initial ize ................................................................................................................ 48
5.2.16 set_stack_si ze................................................................................................................. 49
5.2.17 next_trigger .................................................................................................................... 50
5.2.18 wait................................................................................................................................. 52
5.2.19 Posi ti onal port binding................................................................................................... 53
5.2.20 bef ore_end_of _el aboration, end_of_elaborati on, start_of _si mulati on,
end_of _simulati on ......................................................................................................... 55
5.2.21 get_chil d_objects and get_chi ld_events ........................................................................ 55
5.2.22 sc_gen_unique_name..................................................................................................... 56
5.2.23 sc_behavior and sc_channel ........................................................................................... 56
5.3 sc_modul e_name ....................................................................................................................... 57
5.3.1 Descripti on..................................................................................................................... 57
5.3.2 Class defi nition .............................................................................................................. 57
5.3.3 Constraints on usage...................................................................................................... 58
5.3.4 Module hierarchy ........................................................................................................... 58
5.3.5 Member f unctions.......................................................................................................... 58
5.4 sc_sensitive.............................................................................................................................. 60
5.4.1 Descripti on..................................................................................................................... 60
5.4.2 Class defi nition .............................................................................................................. 60
5.4.3 Constraints on usage...................................................................................................... 60
5.4.4 operator<<...................................................................................................................... 60
5.5 sc_spawn_opti ons and sc_spawn............................................................................................... 61
5.5.1 Descripti on..................................................................................................................... 61
x
Copyright 2012 IEEE. All rights reserved.
5.5.2 Class defi nition .............................................................................................................. 61
5.5.3 Constraints on usage...................................................................................................... 62
5.5.4 Constructors................................................................................................................... 62
5.5.5 Member f unctions.......................................................................................................... 63
5.5.6 sc_spawn........................................................................................................................ 64
5.5.7 SC_FORK and SC_JOIN............................................................................................... 66
5.6 sc_process_handl e ..................................................................................................................... 67
5.6.1 Descripti on..................................................................................................................... 67
5.6.2 Class defi nition .............................................................................................................. 68
5.6.3 Constraints on usage...................................................................................................... 69
5.6.4 Constructors................................................................................................................... 69
5.6.5 Member f unctions.......................................................................................................... 69
5.6.6 Member f unctions f or process control ........................................................................... 73
5.6.7 sc_get_current_process_handle ..................................................................................... 88
5.6.8 sc_i s_unwinding ............................................................................................................ 89
5.7 sc_event_finder and sc_event_fi nder_t ..................................................................................... 90
5.7.1 Descripti on..................................................................................................................... 90
5.7.2 Class defi nition .............................................................................................................. 90
5.7.3 Constraints on usage...................................................................................................... 90
5.8 sc_event_and_li st and sc_event_or_li st ..................................................................................... 92
5.8.1 Descripti on..................................................................................................................... 92
5.8.2 Class defi nition .............................................................................................................. 92
5.8.3 Constraints and usage .................................................................................................... 93
5.8.4 Constructors, destructor, assi gnment ............................................................................. 93
5.8.5 Member f unctions and operators ................................................................................... 94
5.9 sc_event_and_exprand sc_event_or_expr............................................................................ 95
5.9.1 Descripti on..................................................................................................................... 95
5.9.2 Class defi nition .............................................................................................................. 95
5.9.3 Constraints on usage...................................................................................................... 96
5.9.4 Operators........................................................................................................................ 96
5.10 sc_event ..................................................................................................................................... 97
5.10.1 Descripti on..................................................................................................................... 97
5.10.2 Class defi nition .............................................................................................................. 97
5.10.3 Constraints on usage...................................................................................................... 98
5.10.4 Constructors, destructor, and event naming.................................................................. 98
5.10.5 Functi ons f or nami ng and hi erarchy traversal .............................................................. 99
5.10.6 notif y and cancel .......................................................................................................... 100
5.10.7 Event l ists..................................................................................................................... 101
5.10.8 Mul tipl e event notif icati ons......................................................................................... 101
5.11 sc_time..................................................................................................................................... 101
5.11.1 Descripti on................................................................................................................... 101
5.11.2 Class defi nition ............................................................................................................ 101
5.11.3 Time resolution............................................................................................................ 102
5.11.4 Function sc_max_time................................................................................................. 103
5.11.5 Functions and operators............................................................................................... 103
5.11.6 SC_ZERO_TIME ........................................................................................................ 103
5.12 sc_port...................................................................................................................................... 104
5.12.1 Descripti on................................................................................................................... 104
5.12.2 Class defi nition ............................................................................................................ 104
5.12.3 Template parameters.................................................................................................... 105
5.12.4 Constraints on usage.................................................................................................... 106
5.12.5 Constructors................................................................................................................. 107
5.12.6 kind .............................................................................................................................. 107
5.12.7 Named port binding ..................................................................................................... 108
xi
Copyright 2012 IEEE. All rights reserved.
5.12.8 Member functi ons for bound ports and port-to-port binding....................................... 109
5.12.9 bef ore_end_of _el aboration, end_of_elaborati on, start_of _si mulati on,
end_of _simulati on ....................................................................................................... 112
5.13 sc_export .................................................................................................................................. 113
5.13.1 Descripti on................................................................................................................... 113
5.13.2 Class defi nition ............................................................................................................ 113
5.13.3 Template parameters.................................................................................................... 114
5.13.4 Constraints on usage.................................................................................................... 114
5.13.5 Constructors................................................................................................................. 114
5.13.6 kind .............................................................................................................................. 114
5.13.7 Export bindi ng ............................................................................................................. 115
5.13.8 Member functi ons for bound exports and export-to-export binding ........................... 116
5.13.9 bef ore_end_of _el aboration, end_of_elaborati on, start_of _si mulati on,
end_of _simulati on ....................................................................................................... 117
5.14 sc_i nterface.............................................................................................................................. 117
5.14.1 Descripti on................................................................................................................... 117
5.14.2 Class defi nition ............................................................................................................ 117
5.14.3 Constraints on usage.................................................................................................... 118
5.14.4 register_port ................................................................................................................. 118
5.14.5 def aul t_event ................................................................................................................ 119
5.15 sc_prim_channel ...................................................................................................................... 119
5.15.1 Descripti on................................................................................................................... 119
5.15.2 Class defi nition ............................................................................................................ 119
5.15.3 Constraints on usage.................................................................................................... 121
5.15.4 Constructors, destructor, and hierarchi cal names........................................................ 121
5.15.5 kind .............................................................................................................................. 121
5.15.6 request_update and update........................................................................................... 121
5.15.7 next_trigger and wait ................................................................................................... 123
5.15.8 bef ore_end_of _el aboration, end_of_elaborati on, start_of _si mulati on,
end_of _simulati on ....................................................................................................... 123
5.16 sc_obj ect .................................................................................................................................. 124
5.16.1 Descripti on................................................................................................................... 124
5.16.2 Class defi nition ............................................................................................................ 124
5.16.3 Constraints on usage.................................................................................................... 125
5.16.4 Constructors and destructor ......................................................................................... 126
5.16.5 name, basename, and ki nd........................................................................................... 126
5.16.6 pri nt and dump............................................................................................................. 127
5.16.7 Functi ons f or obj ect hi erarchy traversal ...................................................................... 127
5.16.8 Member f uncti ons f or attri butes .................................................................................. 129
5.17 Hi erarachi cal nami ng of obj ects and events............................................................................ 130
5.18 sc_attr_base.............................................................................................................................. 131
5.18.1 Descripti on................................................................................................................... 131
5.18.2 Class defi nition ............................................................................................................ 131
5.18.3 Member f unctions........................................................................................................ 132
5.19 sc_attribute............................................................................................................................... 132
5.19.1 Descripti on................................................................................................................... 132
5.19.2 Class defi nition ............................................................................................................ 132
5.19.3 Template parameters.................................................................................................... 132
5.19.4 Member f uncti ons and data members.......................................................................... 132
5.20 sc_attr_cl tn............................................................................................................................... 133
5.20.1 Descripti on................................................................................................................... 133
5.20.2 Class defi nition ............................................................................................................ 133
5.20.3 Constraints on usage.................................................................................................... 133
5.20.4 Iterators........................................................................................................................ 133
xii
Copyright 2012 IEEE. All rights reserved.
6. Predefi ned channel class def ini ti ons................................................................................................ 135
6.1 sc_si gnal_i n_i f ......................................................................................................................... 135
6.1.1 Descripti on................................................................................................................... 135
6.1.2 Class defi nition ............................................................................................................ 135
6.1.3 Member f unctions........................................................................................................ 135
6.2 sc_signal_in_if <bool > and sc_signal _i n_if <sc_dt::sc_logic>................................................. 136
6.2.1 Descripti on................................................................................................................... 136
6.2.2 Class defi nition ............................................................................................................ 136
6.2.3 Member f unctions........................................................................................................ 137
6.3 sc_si gnal_i nout_i f .................................................................................................................... 137
6.3.1 Descripti on................................................................................................................... 137
6.3.2 Class defi nition ............................................................................................................ 137
6.3.3 Member f unctions........................................................................................................ 138
6.4 sc_si gnal ................................................................................................................................... 139
6.4.1 Descripti on................................................................................................................... 139
6.4.2 Class defi nition ............................................................................................................ 139
6.4.3 Template parameter T.................................................................................................. 140
6.4.4 Reading and writing si gnal s......................................................................................... 140
6.4.5 Constructors................................................................................................................. 141
6.4.6 register_port ................................................................................................................. 141
6.4.7 Member f unctions f or reading ..................................................................................... 141
6.4.8 Member functi ons for wri ti ng...................................................................................... 142
6.4.9 Member f unctions f or events....................................................................................... 142
6.4.10 Di agnostic member f uncti ons...................................................................................... 143
6.4.11 operator<<.................................................................................................................... 143
6.5 sc_signal<bool,WRI TER_POLICY> and sc_signal<sc_dt::sc_logic,WRI TER_POLI CY> .. 144
6.5.1 Descripti on................................................................................................................... 144
6.5.2 Class defi nition ............................................................................................................ 144
6.5.3 Member f unctions........................................................................................................ 146
6.6 sc_buf fer .................................................................................................................................. 147
6.6.1 Descripti on................................................................................................................... 147
6.6.2 Class defi nition ............................................................................................................ 147
6.6.3 Constructors................................................................................................................. 147
6.6.4 Member f unctions........................................................................................................ 148
6.7 sc_cl ock ................................................................................................................................... 149
6.7.1 Descripti on................................................................................................................... 149
6.7.2 Class defi nition ............................................................................................................ 149
6.7.3 Characteri stic properties.............................................................................................. 150
6.7.4 Constructors................................................................................................................. 150
6.7.5 write............................................................................................................................. 151
6.7.6 Diagnostic member functi ons...................................................................................... 151
6.7.7 bef ore_end_of_elaborati on .......................................................................................... 151
6.7.8 sc_i n_clk ...................................................................................................................... 151
6.8 sc_i n......................................................................................................................................... 152
6.8.1 Descripti on................................................................................................................... 152
6.8.2 Class defi nition ............................................................................................................ 152
6.8.3 Member f unctions........................................................................................................ 153
6.8.4 Function sc_trace......................................................................................................... 153
6.8.5 end_of_elaboration ...................................................................................................... 153
6.9 sc_i n<bool > and sc_i n<sc_dt::sc_logic>................................................................................. 153
6.9.1 Descripti on................................................................................................................... 153
6.9.2 Class defi nition ............................................................................................................ 154
6.9.3 Member f unctions........................................................................................................ 155
xii i
Copyright 2012 IEEE. All rights reserved.
6.10 sc_i nout .................................................................................................................................... 156
6.10.1 Descripti on................................................................................................................... 156
6.10.2 Class defi nition ............................................................................................................ 156
6.10.3 Member f unctions........................................................................................................ 157
6.10.4 ini ti al ize ....................................................................................................................... 157
6.10.5 Function sc_trace......................................................................................................... 157
6.10.6 end_of_elaborati on ...................................................................................................... 158
6.10.7 Bindi ng......................................................................................................................... 158
6.11 sc_i nout<bool> and sc_inout<sc_dt::sc_l ogi c> ...................................................................... 158
6.11.1 Descripti on................................................................................................................... 158
6.11.2 Class defi nition ............................................................................................................ 158
6.11.3 Member f unctions........................................................................................................ 160
6.12 sc_out ....................................................................................................................................... 160
6.12.1 Descripti on................................................................................................................... 160
6.12.2 Class defi nition ............................................................................................................ 160
6.12.3 Member f unctions........................................................................................................ 161
6.13 sc_si gnal_resolved................................................................................................................... 161
6.13.1 Descripti on................................................................................................................... 161
6.13.2 Class defi nition ............................................................................................................ 161
6.13.3 Constructors................................................................................................................. 162
6.13.4 Resol ution semantics................................................................................................... 162
6.13.5 Member f unctions........................................................................................................ 163
6.14 sc_i n_resol ved ......................................................................................................................... 164
6.14.1 Descripti on................................................................................................................... 164
6.14.2 Class defi nition ............................................................................................................ 164
6.14.3 Member f unctions........................................................................................................ 165
6.15 sc_i nout_resolved .................................................................................................................... 165
6.15.1 Descripti on................................................................................................................... 165
6.15.2 Class defi nition ............................................................................................................ 165
6.15.3 Member f unctions........................................................................................................ 166
6.16 sc_out_resol ved ....................................................................................................................... 166
6.16.1 Descripti on................................................................................................................... 166
6.16.2 Class defi nition ............................................................................................................ 166
6.16.3 Member f unctions........................................................................................................ 167
6.17 sc_si gnal_rv ............................................................................................................................. 167
6.17.1 Descripti on................................................................................................................... 167
6.17.2 Class defi nition ............................................................................................................ 167
6.17.3 Semantics and member functi ons ................................................................................ 167
6.18 sc_i n_rv.................................................................................................................................... 168
6.18.1 Descripti on................................................................................................................... 168
6.18.2 Class defi nition ............................................................................................................ 168
6.18.3 Member f unctions........................................................................................................ 169
6.19 sc_i nout_rv............................................................................................................................... 169
6.19.1 Descripti on................................................................................................................... 169
6.19.2 Class defi nition ............................................................................................................ 169
6.19.3 Member f unctions........................................................................................................ 170
6.20 sc_out_rv.................................................................................................................................. 170
6.20.1 Descripti on................................................................................................................... 170
6.20.2 Class defi nition ............................................................................................................ 170
6.20.3 Member f unctions........................................................................................................ 171
6.21 sc_f if o_in_if ............................................................................................................................. 171
6.21.1 Descripti on................................................................................................................... 171
6.21.2 Class defi nition ............................................................................................................ 171
6.21.3 Member f unctions........................................................................................................ 172
xiv
Copyright 2012 IEEE. All rights reserved.
6.22 sc_f if o_out_if ........................................................................................................................... 172
6.22.1 Descripti on................................................................................................................... 172
6.22.2 Class defi nition ............................................................................................................ 172
6.22.3 Member f unctions........................................................................................................ 173
6.23 sc_f if o ...................................................................................................................................... 173
6.23.1 Descripti on................................................................................................................... 173
6.23.2 Class defi nition ............................................................................................................ 173
6.23.3 Template parameter T.................................................................................................. 174
6.23.4 Constructors................................................................................................................. 175
6.23.5 register_port ................................................................................................................. 175
6.23.6 Member f uncti ons f or reading ..................................................................................... 175
6.23.7 Member functi ons for wri ting...................................................................................... 176
6.23.8 The update phase ......................................................................................................... 176
6.23.9 Member f uncti ons f or events....................................................................................... 177
6.23.10Member f uncti ons for avail abl e values and f ree sl ots ................................................. 177
6.23.11Diagnostic member functi ons...................................................................................... 177
6.23.12operator<<.................................................................................................................... 177
6.24 sc_f if o_in ................................................................................................................................. 178
6.24.1 Descripti on................................................................................................................... 178
6.24.2 Class defi nition ............................................................................................................ 178
6.24.3 Member f unctions........................................................................................................ 179
6.25 sc_f if o_out ............................................................................................................................... 179
6.25.1 Descripti on................................................................................................................... 179
6.25.2 Class defi nition ............................................................................................................ 179
6.25.3 Member f unctions........................................................................................................ 180
6.26 sc_mutex_i f .............................................................................................................................. 182
6.26.1 Descripti on................................................................................................................... 182
6.26.2 Class defi nition ............................................................................................................ 182
6.26.3 Member f unctions........................................................................................................ 182
6.27 sc_mutex .................................................................................................................................. 182
6.27.1 Descripti on................................................................................................................... 182
6.27.2 Class defi nition ............................................................................................................ 182
6.27.3 Constructors................................................................................................................. 183
6.27.4 Member f unctions........................................................................................................ 183
6.28 sc_semaphore_if ...................................................................................................................... 184
6.28.1 Descripti on................................................................................................................... 184
6.28.2 Class defi nition ............................................................................................................ 184
6.28.3 Member f unctions........................................................................................................ 184
6.29 sc_semaphore........................................................................................................................... 185
6.29.1 Descripti on................................................................................................................... 185
6.29.2 Class defi nition ............................................................................................................ 185
6.29.3 Constructors................................................................................................................. 185
6.29.4 Member f unctions........................................................................................................ 185
6.30 sc_event_queue........................................................................................................................ 186
6.30.1 Descripti on................................................................................................................... 186
6.30.2 Class defi nition ............................................................................................................ 186
6.30.3 Constraints on usage.................................................................................................... 187
6.30.4 Constructors................................................................................................................. 187
6.30.5 kind .............................................................................................................................. 187
6.30.6 Member f unctions........................................................................................................ 187
7. SystemC data types.......................................................................................................................... 189
7.1 I ntroducti on.............................................................................................................................. 189
xv
Copyright 2012 IEEE. All rights reserved.
7.2 Common characteri stics........................................................................................................... 191
7.2.1 Ini ti al izati on and assi gnment operators....................................................................... 192
7.2.2 Precision of ari thmetic expressi ons............................................................................. 193
7.2.3 Base class default word length..................................................................................... 193
7.2.4 Word l ength ................................................................................................................. 194
7.2.5 Bit-select ...................................................................................................................... 194
7.2.6 Part-select..................................................................................................................... 195
7.2.7 Concatenati on .............................................................................................................. 196
7.2.8 Reduction operators..................................................................................................... 197
7.2.9 Integer conversi on........................................................................................................ 198
7.2.10 String input and output ................................................................................................ 198
7.2.11 Conversi on of appl icati on-def ined types in integer expressi ons ................................. 199
7.3 Stri ng l iterals............................................................................................................................ 199
7.4 sc_value_base........................................................................................................................ 201
7.4.1 Descripti on................................................................................................................... 201
7.4.2 Class defi nition ............................................................................................................ 201
7.4.3 Constraints on usage.................................................................................................... 201
7.4.4 Member f unctions........................................................................................................ 202
7.5 Li mited-preci si on i nteger types............................................................................................... 202
7.5.1 Type defi ni ti ons........................................................................................................... 202
7.5.2 sc_i nt_base................................................................................................................... 203
7.5.3 sc_uint_base................................................................................................................. 208
7.5.4 sc_i nt ............................................................................................................................ 213
7.5.5 sc_uint .......................................................................................................................... 215
7.5.6 Bit-selects..................................................................................................................... 217
7.5.7 Part-selects................................................................................................................... 222
7.6 Fi ni te-preci si on i nteger types................................................................................................... 227
7.6.1 Type defi ni ti ons........................................................................................................... 227
7.6.2 Constraints on usage.................................................................................................... 227
7.6.3 sc_signed...................................................................................................................... 227
7.6.4 sc_unsi gned.................................................................................................................. 234
7.6.5 sc_bigi nt ....................................................................................................................... 240
7.6.6 sc_biguint ..................................................................................................................... 242
7.6.7 Bit-selects..................................................................................................................... 244
7.6.8 Part-selects................................................................................................................... 248
7.7 I nteger concatenations ............................................................................................................. 253
7.7.1 Descripti on................................................................................................................... 253
7.7.2 Class defi nition ............................................................................................................ 253
7.7.3 Constraints on usage.................................................................................................... 255
7.7.4 Assi gnment operators .................................................................................................. 255
7.7.5 Implici t type conversion .............................................................................................. 255
7.7.6 Explici t type conversion .............................................................................................. 255
7.7.7 Other member functions .............................................................................................. 256
7.8 Generi c base proxy class.......................................................................................................... 256
7.8.1 Descripti on................................................................................................................... 256
7.8.2 Class defi nition ............................................................................................................ 256
7.8.3 Constraints on usage.................................................................................................... 256
7.9 Logic and vector types............................................................................................................. 257
7.9.1 Type defi ni ti ons........................................................................................................... 257
7.9.2 sc_l ogi c ........................................................................................................................ 257
7.9.3 sc_bv_base................................................................................................................... 262
7.9.4 sc_l v_base.................................................................................................................... 267
7.9.5 sc_bv ............................................................................................................................ 273
7.9.6 sc_l v ............................................................................................................................. 275
xvi
Copyright 2012 IEEE. All rights reserved.
7.9.7 Bit-selects..................................................................................................................... 277
7.9.8 Part-selects................................................................................................................... 280
7.9.9 Concatenati ons............................................................................................................. 286
7.10 Fi xed-poi nt types..................................................................................................................... 293
7.10.1 Fixed-point representati on ........................................................................................... 293
7.10.2 Fixed-point type conversi on ........................................................................................ 294
7.10.3 Fixed-point data types.................................................................................................. 295
7.10.4 Fixed-point expressions and operations....................................................................... 296
7.10.5 Bit and part selecti on ................................................................................................... 299
7.10.6 Variable-preci si on f ixed-point value li mits................................................................. 300
7.10.7 Fixed-poi nt word l ength and mode.............................................................................. 300
7.10.8 Conversi ons to character stri ng.................................................................................... 302
7.10.9 Finite word-l ength ef fects............................................................................................ 304
7.10.10sc_f xnum...................................................................................................................... 327
7.10.11sc_f xnum_f ast .............................................................................................................. 332
7.10.12sc_f xval ........................................................................................................................ 337
7.10.13sc_f xval_f ast ................................................................................................................ 341
7.10.14sc_f ix............................................................................................................................ 346
7.10.15sc_ufi x.......................................................................................................................... 349
7.10.16sc_f ix_fast .................................................................................................................... 352
7.10.17sc_ufi x_fast .................................................................................................................. 355
7.10.18sc_f ixed........................................................................................................................ 358
7.10.19sc_ufi xed...................................................................................................................... 360
7.10.20sc_f ixed_f ast ................................................................................................................ 362
7.10.21sc_ufi xed_f ast .............................................................................................................. 365
7.10.22Bit-selects..................................................................................................................... 367
7.10.23Part-sel ects................................................................................................................... 369
7.11 Contexts ................................................................................................................................... 375
7.11.1 sc_l ength_param.......................................................................................................... 375
7.11.2 sc_l ength_context ........................................................................................................ 377
7.11.3 sc_f xtype_params ........................................................................................................ 378
7.11.4 sc_f xtype_context ........................................................................................................ 380
7.11.5 sc_f xcast_switch .......................................................................................................... 381
7.11.6 sc_f xcast_context ......................................................................................................... 382
7.12 Control of stri ng representati on ............................................................................................... 383
7.12.1 Descripti on................................................................................................................... 383
7.12.2 Class defi nition ............................................................................................................ 383
7.12.3 Functions...................................................................................................................... 384
8. SystemC util ities.............................................................................................................................. 385
8.1 Trace fi les ................................................................................................................................ 385
8.1.1 Class defi ni ti on and f unction declarations................................................................... 385
8.1.2 sc_trace_fi le................................................................................................................. 385
8.1.3 sc_create_vcd_trace_f il e.............................................................................................. 386
8.1.4 sc_close_vcd_trace_f ile............................................................................................... 386
8.1.5 sc_write_comment ....................................................................................................... 386
8.1.6 sc_trace ........................................................................................................................ 386
8.2 sc_report................................................................................................................................... 388
8.2.1 Descripti on................................................................................................................... 388
8.2.2 Class defi nition ............................................................................................................ 388
8.2.3 Constraints on usage.................................................................................................... 389
8.2.4 sc_verbosi ty ................................................................................................................. 389
8.2.5 sc_severity ................................................................................................................... 389
xvii
Copyright 2012 IEEE. All rights reserved.
8.2.6 Copy constructor and assignment ................................................................................ 390
8.2.7 Member f unctions........................................................................................................ 390
8.3 sc_report_handl er..................................................................................................................... 391
8.3.1 Descripti on................................................................................................................... 391
8.3.2 Class defi nition ............................................................................................................ 391
8.3.3 Constraints on usage.................................................................................................... 393
8.3.4 sc_actions..................................................................................................................... 393
8.3.5 report ............................................................................................................................ 393
8.3.6 set_acti ons.................................................................................................................... 394
8.3.7 stop_af ter ..................................................................................................................... 395
8.3.8 get_count...................................................................................................................... 396
8.3.9 Verbosity l evel ............................................................................................................. 396
8.3.10 suppress and force........................................................................................................ 396
8.3.11 set_handler ................................................................................................................... 397
8.3.12 get_new_acti on_i d....................................................................................................... 398
8.3.13 sc_i nterrupt_here and sc_stop_here............................................................................. 398
8.3.14 get_cached_report and cl ear_cached_report................................................................ 398
8.3.15 set_l og_f il e_name and get_log_fi le_name.................................................................. 399
8.4 sc_exception............................................................................................................................. 399
8.4.1 Descripti on................................................................................................................... 399
8.4.2 Class defi nition ............................................................................................................ 399
8.5 sc_vector .................................................................................................................................. 400
8.5.1 Descripti on................................................................................................................... 400
8.5.2 Class defi nition ............................................................................................................ 400
8.5.3 Constraints on usage.................................................................................................... 403
8.5.4 Constructors and destructors........................................................................................ 403
8.5.5 ini t and create_element ................................................................................................ 404
8.5.6 kind, si ze, get_el ements............................................................................................... 405
8.5.7 operator[ ] and at ........................................................................................................... 406
8.5.8 Iterators........................................................................................................................ 406
8.5.9 bind .............................................................................................................................. 406
8.5.10 sc_assemble_vector ..................................................................................................... 408
8.6 Util ity f unctions....................................................................................................................... 410
8.6.1 Function declarations................................................................................................... 410
8.6.2 sc_abs........................................................................................................................... 411
8.6.3 sc_max ......................................................................................................................... 411
8.6.4 sc_mi n.......................................................................................................................... 411
8.6.5 Version and copyright.................................................................................................. 411
9. Overview of TLM-2.0...................................................................................................................... 413
9.1 Compl iance with the TLM-2.0 standard.................................................................................. 414
10. Introduction to TLM-2.0.................................................................................................................. 415
10.1 Background.............................................................................................................................. 415
10.2 Transaction-l evel modeli ng, use cases, and abstraction .......................................................... 415
10.3 Coding styles............................................................................................................................ 416
10.3.1 Unti med coding style................................................................................................... 416
10.3.2 Loosely-timed codi ng styl e and temporal decoupli ng................................................. 417
10.3.3 Synchronizati on i n l oosely-timed model s.................................................................... 418
10.3.4 Approximatel y-timed codi ng style .............................................................................. 418
10.3.5 Characterization of loosely-ti med and approximatel y-ti med coding styles ................ 419
10.3.6 Switchi ng between l oosely-timed and approximatel y-timed model ing ...................... 419
xviii
Copyright 2012 IEEE. All rights reserved.
10.3.7 Cycl e-accurate modeli ng ............................................................................................. 419
10.3.8 Blocking versus non-bl ocking transport i nterf aces ..................................................... 419
10.3.9 Use cases and codi ng styles......................................................................................... 420
10.4 I niti ators, targets, sockets, and transacti on bridges ................................................................. 420
10.5 DMI and debug transport interfaces ........................................................................................ 423
10.6 Combi ned interfaces and sockets............................................................................................. 423
10.7 Namespaces ............................................................................................................................. 423
10.8 Header fi les and versi on numbers............................................................................................ 424
10.8.1 Sof tware versi on i nf ormation ...................................................................................... 424
10.8.2 Defi niti ons ................................................................................................................... 424
10.8.3 Rules ............................................................................................................................ 425
11. TLM-2.0 core interf aces.................................................................................................................. 426
11.1 Transport i nterf aces ................................................................................................................. 426
11.1.1 Blocking transport i nterface......................................................................................... 426
11.1.2 Non-blocking transport i nterf ace................................................................................. 430
11.1.3 Timi ng annotati on wi th the transport i nterfaces.......................................................... 438
11.1.4 Mi grati on path from TLM-1........................................................................................ 442
11.2 Di rect memory interface.......................................................................................................... 442
11.2.1 Introduction.................................................................................................................. 442
11.2.2 Class defi nition ............................................................................................................ 443
11.2.3 get_di rect_mem_ptr method........................................................................................ 444
11.2.4 templ ate argument and tlm_generic_payload class..................................................... 445
11.2.5 tl m_dmi cl ass............................................................................................................... 445
11.2.6 invali date_direct_mem_ptr method ............................................................................. 448
11.2.7 DMI versus transport ................................................................................................... 449
11.2.8 DMI and temporal decoupl ing..................................................................................... 449
11.2.9 Opti mizati on using a DMI hi nt .................................................................................... 450
11.3 Debug transport i nterf ace......................................................................................................... 450
11.3.1 Introduction.................................................................................................................. 450
11.3.2 Class defi nition ............................................................................................................ 450
11.3.3 TRANS templ ate argument and tlm_generic_payl oad class....................................... 451
11.3.4 Rules ............................................................................................................................ 451
12. TLM-2.0 gl obal quantum................................................................................................................. 453
12.1 I ntroducti on.............................................................................................................................. 453
12.2 Header fi le................................................................................................................................ 453
12.3 Cl ass def ini tion ........................................................................................................................ 453
12.4 Cl ass tl m_gl obal _quantum ...................................................................................................... 454
13. Combined TLM-2.0 interf aces and sockets..................................................................................... 455
13.1 Combined interfaces ................................................................................................................ 455
13.1.1 Introduction.................................................................................................................. 455
13.1.2 Class defi nition ............................................................................................................ 455
13.2 I nitiator and target sockets....................................................................................................... 456
13.2.1 Introduction.................................................................................................................. 456
13.2.2 Class defi nition ............................................................................................................ 456
13.2.3 Classes tlm_base_ini ti ator_socket_b and tlm_base_target_socket_b.......................... 460
13.2.4 Classes tlm_base_ini tiator_socket and tl m_base_target_socket.................................. 460
13.2.5 Cl asses tlm_initiator_socket and tlm_target_socket .................................................... 461
xix
Copyright 2012 IEEE. All rights reserved.
14. TLM-2.0 generic payl oad ................................................................................................................ 465
14.1 I ntroducti on.............................................................................................................................. 465
14.2 Extensions and interoperabil ity ............................................................................................... 465
14.2.1 Use the generic payload di rectl y, wi th ignorable extensions....................................... 466
14.2.2 Defi ne a new protocol traits class containing a typedef f or tl m_generi c_payload...... 467
14.2.3 Defi ne a new protocol trai ts cl ass and a new transacti on type .................................... 467
14.3 Generic payl oad attri butes and methods.................................................................................. 467
14.4 Cl ass def ini tion ........................................................................................................................ 468
14.5 Generi c payload memory management ................................................................................... 470
14.6 Constructors, assi gnment, and destructor ................................................................................ 474
14.7 Default val ues and modif iabil ity of attributes ......................................................................... 474
14.8 Option attribute........................................................................................................................ 476
14.9 Command attri bute .................................................................................................................. 477
14.10Address attribute..................................................................................................................... 478
14.11Data pointer attribute.............................................................................................................. 479
14.12Data l ength attri bute................................................................................................................ 480
14.13Byte enabl e pointer attribute................................................................................................... 480
14.14Byte enabl e l ength attri bute.................................................................................................... 481
14.15Streaming width attri bute........................................................................................................ 482
14.16DMI all owed attri bute............................................................................................................. 482
14.17Response status attribute......................................................................................................... 483
14.17.1The standard error response......................................................................................... 484
14.18Endianness.............................................................................................................................. 487
14.18.1Introduction.................................................................................................................. 487
14.18.2Rules ............................................................................................................................ 488
14.19Helper f unctions to determine host endi anness ...................................................................... 490
14.19.1Introduction.................................................................................................................. 490
14.19.2Defi ni ti on..................................................................................................................... 490
14.19.3Rules ............................................................................................................................ 491
14.20Helper f unctions f or endi anness conversion........................................................................... 491
14.20.1Introduction.................................................................................................................. 491
14.20.2Defi ni ti on..................................................................................................................... 492
14.20.3Rules ............................................................................................................................ 492
14.21Generi c payload extensions.................................................................................................... 494
14.21.1Introduction.................................................................................................................. 494
14.21.2Rati onal e...................................................................................................................... 494
14.21.3Extensi on pointers, objects and transacti on bri dges.................................................... 495
14.21.4Rules ............................................................................................................................ 495
15. TLM-2.0 base protocol and phases.................................................................................................. 500
15.1 Phases....................................................................................................................................... 500
15.1.1 Introduction.................................................................................................................. 500
15.1.2 Class defi nition ............................................................................................................ 500
15.1.3 Rules ............................................................................................................................ 501
15.2 Base protocol ........................................................................................................................... 502
15.2.1 Introduction.................................................................................................................. 502
15.2.2 Class defi nition ............................................................................................................ 503
15.2.3 Base protocol phase sequences.................................................................................... 503
15.2.4 Permi tted phase transitions.......................................................................................... 505
15.2.5 Ignorable phases .......................................................................................................... 508
15.2.6 Base protocol timi ng parameters and fl ow control ...................................................... 510
15.2.7 Base protocol rul es concerning ti ming annotati on ...................................................... 514
xx
Copyright 2012 IEEE. All rights reserved.
15.2.8 Base protocol rules concerni ng b_transport................................................................. 514
15.2.9 Base protocol rul es concerning request and response ordering................................... 515
15.2.10Base protocol rul es for switching between b_transport and nb_transport ................... 516
15.2.11Other base protocol rules............................................................................................. 517
15.2.12Summary of base protocol transaction ordering rules................................................. 517
15.2.13Guideli nes for creati ng base-protocol-compli ant components.................................... 517
16. TLM-2.0 util iti es.............................................................................................................................. 521
16.1 Conveni ence sockets................................................................................................................ 521
16.1.1 Introduction.................................................................................................................. 521
16.1.2 Simpl e sockets............................................................................................................. 523
16.1.3 Tagged si mple sockets................................................................................................. 529
16.1.4 Multi-sockets ............................................................................................................... 532
16.2 Quantum keeper ....................................................................................................................... 537
16.2.1 Introduction.................................................................................................................. 537
16.2.2 Header f il e.................................................................................................................... 537
16.2.3 Class defi nition ............................................................................................................ 537
16.2.4 General gui del ines f or processes usi ng temporal decoupli ng...................................... 538
16.2.5 Class tlm_quantumkeeper ............................................................................................ 539
16.3 Payload event queue ................................................................................................................ 541
16.3.1 Introduction.................................................................................................................. 541
16.3.2 Header f il e.................................................................................................................... 542
16.3.3 Class defi nition ............................................................................................................ 542
16.3.4 Rules ............................................................................................................................ 543
16.4 I nstance-speci fi c extensi ons .................................................................................................... 544
16.4.1 Introduction.................................................................................................................. 544
16.4.2 Header f il e.................................................................................................................... 544
16.4.3 Class defi nition ............................................................................................................ 544
17. TLM-1 Message passi ng i nterf ace and anal ysis ports..................................................................... 546
17.1 Put, get, peek, and transport interfaces.................................................................................... 546
17.1.1 Descripti on................................................................................................................... 546
17.1.2 Class Def inition ........................................................................................................... 546
17.1.3 Blocking versus non-bl ocking interf aces..................................................................... 548
17.1.4 Blocking put, get, peek, and transport ......................................................................... 549
17.1.5 Non-blocking i nterf ace methods.................................................................................. 549
17.1.6 Argument passing and transaction li fetime ................................................................. 550
17.1.7 Constraints on the transacti on data type...................................................................... 551
17.2 TLM-1 fi fo interfaces .............................................................................................................. 551
17.2.1 Descripti on................................................................................................................... 551
17.2.2 Cl ass Defi ni ti on ........................................................................................................... 551
17.2.3 Member f uncti ons........................................................................................................ 552
17.3 tlm_f if o .................................................................................................................................... 552
17.3.1 Descripti on................................................................................................................... 552
17.3.2 Class Def inition ........................................................................................................... 553
17.3.3 Template parameter T .................................................................................................. 554
17.3.4 Constructors and destructor ......................................................................................... 554
17.3.5 Member f uncti ons........................................................................................................ 554
17.3.6 Delta cycle semanti cs................................................................................................... 556
17.4 Analysis interface and analysi s ports....................................................................................... 558
17.4.1 Class defi nition ............................................................................................................ 558
17.4.2 Rules ............................................................................................................................ 559
xxi
Copyright 2012 IEEE. All rights reserved.
Annex A (informati ve) I ntroducti on to SystemC ........................................................................................ 562
Annex B (inf ormati ve) Glossary.................................................................................................................. 566
Annex C (informati ve) Deprecated f eatures................................................................................................ 583
Annex D (informati ve) Changes between IEEE Std 1666-2005 and I EEE Std 1666-2011........................ 585
I ndex ............................................................................................................................................................ 589
1
Copyright 2012 IEEE. All rights reserved.
IEEE Standard for Standard
SystemC

Language Reference
Manual
I MPORTANT NOTI CE: This standard is not intended to ensure safety, security, health, or
environmental protection. I mplementers of the standard are responsible for determining appropriate
safety, security, environmental, andhealthpracticesor regulatoryrequirements.
ThisI EEE document ismadeavailablefor use subject to important noticesandlegal disclaimers. These
noticesanddisclaimersappear in all publicationscontainingthisdocument andmaybefoundunder the
heading"I mportant Notice" or "Important NoticesandDisclaimersConcerningIEEE Documents." They
can alsobeobtainedonrequest fromI EEE or viewedat http://standards.ieee.org/I PR/disclaimers.html.
1. Overview
1.1 Scope
This standard defi nes SystemC
1
with Transacti on Level Modeli ng (TLM) asan ANSI standard C++ class
li brary for systemandhardwaredesi gn.
1.2 Purpose
The general purpose of thi s standard i s to provi dea C++-based standard for designers and archi tects who
need to address complex systemsthat areahybrid between hardwareand software.
The speci fi c purpose of this standard i sto provide aprecise and complete defi ni ti on of the SystemC class
li brary including aTLM l ibrary so that a SystemC implementation can be developed wi th referenceto thi s
standard alone. This standard is not intended to serve as a users guide or to provide an introduction to
SystemC, but i t doescontai n useful i nformation for end users.
1
SystemC

isaregistered trademark of theAccel leraSystemsInitiati ve.


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


2
Copyright 2012 IEEE. All rights reserved.
1.3 Subsets
It is anti cipated that tool vendors wi ll create impl ementations that support onl y a subset of this standard or
that i mpose further constrai nts on the use of thi s standard. Such i mplementations are not fully compli ant
wi th this standard but may nevertheless clai mpartial compli ance with this standard and may usethe name
SystemC. Seeal so 9.1 for adescri ption of TLM-2.0-compl iance.
1.4 Relationship with C++
This standard i s cl osely rel ated to the C++ programming language and adheres to the termi nology used i n
ISO/IEC 14882:2003.
2
This standard doesnot seek to restri ct theusageof theC++ programming l anguage;
a SystemC appli cati on may use any of the faci li ti es provided by C++, which in turn may use any of the
facil itiesprovi ded by C. However, wherethefacil itiesprovided by thi sstandard areused, they shal l beused
in accordancewi th therul es and constraints set out i n thisstandard.
This standard defines the publ ic interface to the SystemC class l ibrary and the constrai nts on how those
classes may beused. The SystemC cl ass library may bei mplemented i n any manner whatsoever, provided
only that theobl igati onsimposed by this standard arehonored.
A C++ class li brary may be extended usi ng the mechanisms provi ded by theC++ l anguage. Impl ementors
and usersarefreeto extend SystemCin thi sway, providedthat they do not vi olatethi sstandard.
NOTEIt is possible to create a well-formed C++ programthat is legal according to theC++ programming language
standard but that violatesthisstandard. Animplementationisnot obliged to detect every violation of thisstandard.
3
1.5 Guidance for readers
Readers who arenot entirely famili ar wi th SystemCshould start wi th Annex A, Introduction to SystemC,
which provi des a brief i nformal summary of the subject i ntended to aid in the understandi ng of the
normati vedefini ti ons. Suchreadersmay also find i t helpful to scan theexampl esembedded in thenormati ve
definitions and to see Annex B, Glossary.
Readers should pay close attention to Clause 3, Terminology and conventions used in this standard. An
understanding of the terminology defined i n Clause 3 i s necessary for a precise interpretati on of thi s stan-
dard.
Clause 4, Elaboration and simulation semantics, definesthebehavi or of theSystemCkernel and is central
to an understanding of SystemC. The semantic defi nitions given i n the subsequent cl auses detai li ng the
indi vi dual cl asses arebuil t on thefoundati onsl ai di n Clause4.
The cl auses from Clause 5 onward define the publ ic interface to the SystemC class l ibrary. The fol lowi ng
informati on i sl isted for eachclass:
a) A C++ sourcecodeli sting of theclass defini tion
b) A statement of any constrai ntson theuseof theclassand i ts members
c) A statement of thesemanticsof thecl assand itsmembers
d) For certai nclasses, adescri pti on of functions, typedefs, andmacros associated withtheclass
e) Informativeexamples il lustrating both typical and atypical uses of thecl ass
2
Information onreferencescanbefound in Clause2.
3
Notesi ntext, tables, and figuresaregi ven for information onl y and do not contain requirementsneeded to i mplement thestandard.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


3
Copyright 2012 IEEE. All rights reserved.
Readers shoul d bear in mind that the primary obli gation of a tool vendor i s to impl ement the abstract
semanti csdefined i nClause4, usi ng theframework and constraintsprovi ded by theclassdefini tionsstarting
in Cl ause5.
The clauses from Clause 9 onward defi ne the public interface to the TLM-2.0 class li brary, i ncl udi ng the
classesof thei nteroperabi li ty layer and theuti lities.
Cl ause17 definestheTLM-1 Messagepassi ng interface, including tlm_fifoand anal ysi sports.
Annex A is i ntended to aid thereader in theunderstanding of thestructureand i ntent of the SystemC class
li brary.
Annex B i sagl ossary giving informal descri pti onsof thetermsused in thi sstandard.
Annex C l ists the deprecated features, that i s, features that were present in versi on 2.0.1 of the Open
SystemC Initi ati ve (OSCI) open source proof-of-concept SystemC implementation but are not part of thi s
standard.
Annex D l ists thechangesbetween IEEE Std1666-2005 and IEEE 1666-2011.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


4
Copyright 2012 IEEE. All rights reserved.
2. Normative references
Thefol lowi ng referenced documents are indispensabl efor the appli cation of thisdocument (i.e., they must
beunderstood and used, so each referenced document is cited in text and itsrelati onship to thi sdocument is
expl ai ned). For dated references, only theedi ti on cited appl ies. For undated references, thel atest edi ti on of
thereferenced document (i ncluding any amendmentsor corri genda) appli es.
This standard shal l beused in conj unction with thefol lowi ngpubli cati ons:
ISO/IEC 14882:2003, Programming LanguagesC++.
4
4
ISO/IEC publications are avai lable from the I SO Central Secretariat, Case Postal e 56, 1 rue de Varemb, CH-1211, Genve 20,
Switzerland/Suisse (http://www.iso.ch/). ISO/IEC publ icati ons are also avail abl e in the United States from Global Engi neering
Documents, 15 InvernessWay East, Engl ewood, Colorado 80112, USA (http://gl obal .ihs.com/). El ectronic copi esare avai lable in the
United States from the Ameri can National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://
www.ansi.org/).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


5
Copyright 2012 IEEE. All rights reserved.
3. Terminology and conventions used in this standard
3.1 Terminology
3.1.1 Shall, should, may, can
Theword shal l is used to indicateamandatory requirement.
Theword shoul d isused to recommend aparti cular courseof action, but it doesnot i mposeany obli gati on.
Theword may is used to mean shal l bepermitted(in thesenseof bei ngl egal ly al lowed).
Theword can is used to mean shal l beableto (i n thesenseof being technicall y possi bl e).
In somecases, word usageisqual ified to indi cateon whomtheobl igation fal ls, such as an appl i cati on may
or an i mpl ementati on shal l .
3.1.2 Implementation, application
The word i mpl ementati on is used to mean any speci fi c i mplementation of the ful l SystemC, TLM-1, and
TLM-2.0class librariesasdefi ned in thisstandard, only thepubl ic interfaceof whichneed beexposed to the
appl ication.
Theword appl i cati on i sused to mean aC++ program, wri ttenby an enduser, that usestheSystemC, TLM-
1, and TLM-2.0 class li brari es, that is, usesclasses, functions, or macrosdefi ned in thi sstandard.
3.1.3 Call, called from, derived from
Thetermcal l is taken to mean call di rectl y or indirectly. Call indirectl y meanscal l an intermedi atefunction
that i n turn cal ls thefunction in questi on, wherethechai nof function call smay beextended indefi ni tely.
Simil arly, cal l ed fr om means cal led from di rectl y or i ndi rectl y.
Except whereexpli ci tl y qual ified, thetermder i ved from istaken to mean deri ved di rectl y or i ndi rectl y from.
Deri ved indirectly frommeans derived from oneor moreintermediatebasecl asses.
3.1.4 Specific technical terms
Thefol lowi ng terms are sometimes used to refer to classesand someti mes used to refer to objectsof those
classes. When the di stincti on is important, the usage of the term may be qual ified. For exampl e, a port
i nstance is an object of aclass deri ved from thecl ass sc_port, whereasaport cl ass isa cl assderi ved from
class sc_port.
A modul e is acl ass derived fromtheclass sc_module.
A port is either aclassderived fromthecl ass sc_port or an obj ect of theclasssc_port.
An expor t is an object of theclasssc_export.
An i nter face is acl ass derived fromtheclasssc_interface.
An i nter face pr oper is an abstract cl ass derived fromtheclass sc_interface but not derived fromthe cl ass
sc_object.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


6
Copyright 2012 IEEE. All rights reserved.
A pr i mi ti ve channel i s a non-abstract cl ass derived from one or morei nterfaces and also derived fromthe
classsc_prim_channel.
A hi er ar chi cal channel isanon-abstract classderived fromoneor moreinterfacesand also deri ved fromthe
classsc_module.
A channel isanon-abstract classderivedfromoneor morei nterfaces. A channel may beapri mitivechannel
or a hierarchi cal channel . If not, it i s strongly recommended that a channel be deri ved from the cl ass
sc_object.
An event is anobject of theclasssc_event.
A si gnal is anobject of theclasssc_signal.
A process i nstance is an object of an i mplementati on-defined cl ass deri ved from the class sc_object and
created by one of the three macros SC_METHOD, SC_THREAD, or SC_CTHREAD or by cal li ng the
functi on sc_spawn.
The term process refers to either a process i nstance or to the member function that is associated wi th a
processinstancewhen i t iscreated. Themeani ng is madeclear by thecontext.
A stati c pr ocess is a process created during the construction of the modul e hierarchy or from the
before_end_of_elaborationcal lback.
A dynami c pr ocess is aprocess created from theend_of_elaboration cal lback or duri ngsimul ation.
An unspawned process is a process created by invoking one of the three macros SC_METHOD,
SC_THREAD, or SC_CTHREAD. An unspawned process is typicall y a stati c process, but i t would be a
dynami c process if invoked fromtheend_of_elaboration cal lback.
A spawned process i saprocess created by cal li ng thefuncti on sc_spawn. A spawned process i stypical ly a
dynami c process, but it woul d beastatic processi f sc_spawnis cal led beforetheend of el aboration.
A process handl e is an object of theclass sc_process_handle.
The modul e hi er archy is the total set of module i nstances constructed duri ng el aboration. The term is
sometimes used to include al l of the obj ects i nstantiated within those modules during elaborati on. The
modulehi erarchy is asubset of theobj ect hi erar chy.
The obj ect hi erar chy is the total set of objects of the cl ass sc_object. Part of the object hierarchy is
constructed during elaboration (the modul e hi erar chy) and i ncl udes modul e, port, primi ti ve channel, and
stati c process i nstances. Part i sconstructed dynami call y and destroyed dynami call y duri ng simul ation and
includes dynamic process instances (see5.16). Events do not belong to the obj ect hierarchy, al though l ike
objectsof thecl asssc_object, eventsmay haveahierarchi cal name.
A gi ven instancei swi thi n modul eM if theconstructor of thei nstanceiscall ed (expl ici tly or i mpli citl y) from
the constructor of module M and i f the instance is not within another module instance that is i tself within
moduleM.
A given modul ei ssai d to contai n agi ven instanceif theinstanceiswithi n that module.
A chi l d of agiven moduleis an i nstancethat i swithi n that module.
A parent of agi ven instancei samodul ehaving that instanceasachi ld.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


7
Copyright 2012 IEEE. All rights reserved.
A top-l evel modul e is amodulethat i snot i nstantiated withi n any other module.
The concepts of el aborati on and si mul ati on are defined i n Cl ause 4. The terms duri ng el aborati on and
duri ng si mul ati on indicate that an action may happen at that ti me. Thei mplementati on makesanumber of
cal lbacks to theapplication during el aboration and simul ation. Whether aparticular action isall owed wi thin
aparticular cal lback cannot bei nferredfromthetermsduri ng el abor ati on and duri ng si mul ati on al onebut is
defined i ndetai l in 4.4. For exampl e, anumber of acti ons that arepermittedduri ng el abor ati on areexpl icitly
forbidden duri ng theend_of_elaboration cal lback.
The term duri ng el aborati on includes the constructi on of the modul e hi erarchy and the
before_end_of_elaborationcal lbacks.
The term duri ng el aborati on or si mul ati on includes every phase from the construction of the modul e
hierarchy up to and including thefinal del ta cycle, but neither i ncludes nor excludes activity subsequent to
thefinal del tacycl e. In other words, useof thi sterminfersnothi ng about whether speci fi c acti onsareor are
not permi tted after thefi nal deltacycle.
Thetermduri ng si mul ati on includesthei ni ti ali zati on, eval uation, and updatephasesand any period when
simul ation is paused.
3.2 Syntactical conventions
3.2.1 Implementation-defined
The i tali cized term i mpl ementati on-defi ned i s used where part of a C++ defi ni ti on i s omi tted from this
standard. In such cases, an implementation shall providean appropri atedefini ti on that honorsthesemantics
defined in this standard.
3.2.2 Disabled
Thei tali cized termdi sabl ed is used within aC++ classdefi ni ti on to indi catea group of member functi ons
that shall be di sabled by the i mplementati on so that they cannot be cal led by an appli cati on. The di sabled
member functi ons aretypical ly thedefault constructor, thecopy constructor, or theassi gnment operator.
3.2.3 Ellipsis (...)
An el li psi s, which consi stsof threeconsecutivedots(...), isused to i ndi catethat i rrel evant or repeti ti veparts
of aC++ codeli sting or exampl ehavebeen omitted for cl arity.
3.2.4 Class names
Cl ass names italici zed and annotated wi th a superscript dagger (

) should not be used expli ci tl y within an


appl icati on. Moreover, an appli cation shal l not createan object of such aclass. It i sstrongly recommended
that thegiven classnamebeused. However, an i mplementati on may substituteanalternati vecl assnamein
placeof every occurrenceof aparticular daggeredclassname.
Only thecl ass name is considered here. Whether any part of thedefi nition of the classi si mplementati on-
defined is aseparatei ssue.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


8
Copyright 2012 IEEE. All rights reserved.
Theclassnamesarethefol lowing:
3.2.5 Embolded text
Emboldi ng is used to enhance readabi li ty i n thi s standard but has no si gni fi cance in SystemC itself.
Emboldi ng is used for names of types, cl asses, functions, and operators in runni ng text and i n code
fragments where these names are defi ned. Embol ding is never used for uppercase names of macros,
constants, and enuml iterals.
3.3 Semantic conventions
3.3.1 Class definitions and the inheritance hierarchy
An impl ementation may di ffer fromthi s standard i n that an i mplementati on may introduce addi tional base
classes, class members, and fri ends to theclasses defined in thi s standard. An i mplementati on may modify
theinheri tancehi erarchy by movi ng class membersdefi ned by thi sstandard i nto baseclassesnot defi ned by
thi s standard. Such additions and modificati ons may be made as necessary in order to i mplement the
semanti cs defi ned by this standard or i n order to introduce additi onal functi onali ty not defined by this
standard.
3.3.2 Function definitions and side-effects
This standard explici tl y defi nes the semantics of the C++ functi ons i n the SystemC class l ibrary. Such
functi ons shall not have any side-effects that woul d contradict the behavior explici tl y mandated by this
standard. In general, the reader should assume the common-sense rul e that i f it is expl icitly stated that a
functi onshal l performacti onA, that functi on shall not performany acti on other thanA, either directly or by
cal li ng another function defi ned in this standard. However, a functi on may, and indeed i n certain
circumstances shall , perform any tasksnecessary for resourcemanagement, performanceoptimization, or to
support any ancil lary featuresof an implementation. Asan exampl eof resourcemanagement, it isassumed
that a destructor wi ll perform any tasks necessary to release the resources al located by the corresponding
constructor. As an exampl eof an anci ll ary feature, an i mplementati on could have the constructor for cl ass
sc_moduleincrement acount of thenumber of moduleinstancesin themodulehi erarchy.
3.3.3 Functions whose return type is a reference or a pointer
Many functi ons in this standard return a reference to an obj ect or a pointer to an obj ect; that is, the return
typeof thefunction isareferenceor apoi nter. Thi s subclausegivessomegeneral rul esdefini ng theli feti me
and theval idi ty of such obj ects.
sc_bi nd_pr oxy

sc_fxnum_bi tr ef

sc_si gned_bi tref

sc_ui nt_subref

sc_bi tref

sc_fxnum_fast_bi tref

sc_si gned_bi tref_r

sc_ui nt_subref_r

sc_bi tref_r

sc_fxnum_fast_subr ef

sc_si gned_subr ef

sc_unsi gned_bi tr ef

sc_concatr ef

sc_fxnum_subr ef

sc_si gned_subr ef_r

sc_unsi gned_bi tr ef_r

sc_concr ef

sc_i nt_bi tr ef

sc_subr ef

sc_unsi gned_subref

sc_concr ef_r

sc_i nt_bi tr ef_r

sc_subr ef_r

sc_unsi gned_subref_r

sc_context_begi n

sc_i nt_subref

sc_swi tch

sc_val ue_base

sc_event_and_expr

sc_i nt_subref_r

sc_ui nt_bi tr ef

sc_vector _i ter


sc_event_or _expr

sc_sensi ti ve

sc_ui nt_bi tr ef_r

IEEE Std 1666-2011


IEEE Standard for Standard SystemC

Language Reference Manual


9
Copyright 2012 IEEE. All rights reserved.
An object returned from afuncti on by pointer or by referencei ssaid to bevali d during any peri od in whi ch
the obj ect i s not del eted and the val ueor behavior of theobject remai ns accessibl eto the appli cation. If an
appl ication refers to thereturned object after i t ceasesto bevali d, the behavior of the implementati on shal l
beundefined.
3.3.3.1 Functions that return *this or an actual argument
In certai n cases, the object returned is either an obj ect (*this) returned by reference fromits own member
functi on (for example, theassi gnment operators), or i t i san object that waspassed by referenceasan actual
argument to the functi on being call ed [for example, std::ostream& operator<< (std::ostream&, const
T&)]. In ei ther case, thefunction cal l i tsel f pl acesno addi tional obl igati onson thei mplementation concern-
ing theli feti meand val idity of theobj ect foll owing returnfromthefuncti on call .
3.3.3.2 Functions that return const char*
Certai n functions have the return type const char*; that i s, they return a pointer to a nul l-terminated
character string. Such strings shall remai n val id until the end of theprogramwi th theexcepti on of member
functi on sc_process_handle::nameand member functi onsof cl ass sc_report, wherethei mplementati on i s
only required to keep thestri ngvali d whi letheprocesshandleor report object itself isval id.
3.3.3.3 Functions that return a reference or pointer to an object in the module hierarchy
Certai n functi ons return a reference or poi nter to an object that forms part of the module hi erarchy or a
property of such an obj ect. Thereturntypesof thesefunctionsincludethefol lowi ng:
a) sc_i nterface* // Returnsachannel
b) sc_event& // Returnsanevent
c) sc_event_finder& // Returnsanevent fi nder
d) sc_time& // Returnsaproperty of pri mi ti vechannel sc_cl ock
Thei mplementati on i sobli ged to ensurethat thereturned obj ect is val id either until the channel , event, or
event fi nder i s del eted expli citly by the appli cation or unti l the destruction of the modul e hierarchy,
whichever i ssooner.
3.3.3.4 Functions that return a reference or pointer to a transient object
Certai n functions return a reference or pointer to an object that may be deleted by the appli cati on or the
implementation beforethedestruction of themodulehierarchy. The return typesof thesefuncti onsi ncl ude
thefol lowing:
a) sc_object *
b) sc_event *
c) sc_attr_base*
d) std::stri ng& // Property of an attributeobject
Thefunctionsconcerned arethefol lowi ng:
sc_object* sc_process_handl e::get_parent_object() const;
sc_object* sc_process_handl e::get_process_obj ect() const;
sc_object* sc_obj ect::get_parent_object() const;
sc_object* sc_event::get_parent_obj ect() const;
sc_object* sc_fi nd_object( const char* );
sc_event* sc_find_event( const char* );
sc_attr_base* sc_obj ect::get_attribute( const std::stri ng& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


10
Copyright 2012 IEEE. All rights reserved.
const sc_attr_base* sc_obj ect::get_attri bute( const std::string& ) const;
sc_attr_base* sc_obj ect::remove_attribute( const std::stri ng& );
const std::string& sc_attr_base::name() const;
The i mplementati on i s only obli ged to ensure that the returned reference i s vali d until the sc_object,
sc_event, sc_attr_base, or std::stringobj ect itself is del eted.
Certai n functionsreturn areferencetoan obj ect that representsatransient coll ection of other objects, where
the appl icati on may add or del ete obj ects before the destructi on of the module hierarchy such that the
contentsof thecoll ection woul d bemodified. Thereturn types of thesefuncti ons includethefollowi ng:
a) std::vector< sc_obj ect * > &
b) std::vector< sc_event * > &
c) sc_attr_cltn*
Thefunctionsconcerned arethefol lowi ng:
virtual const std::vector<sc_object*>& sc_module::get_chi ld_obj ects() const;
virtual const std::vector<sc_event*>& sc_modul e::get_child_events() const;
const std::vector<sc_object*>& sc_process_handl e::get_chil d_objects() const;
const std::vector<sc_event*>& sc_process_handl e::get_chil d_events() const;
virtual const std::vector<sc_object*>& sc_object::get_chi ld_obj ects() const;
virtual const std::vector<sc_event*>& sc_obj ect::get_chil d_events() const;
const std::vector<sc_object*>& sc_get_top_level _obj ects();
const std::vector<sc_event*>& sc_get_top_l evel_events();
sc_attr_cltn& sc_obj ect::attr_cltn();
const sc_attr_cltn& sc_obj ect::attr_cl tn() const;
Thei mplementati oni sonly obl iged to ensurethat thereturned obj ect (thevector or col lecti on) isitself val id
until an sc_object, an sc_event, or an attri butei s added or del eted that would affect thecoll ection returned
by thefunction i f i t wereto becall edagai n.
3.3.3.5 Functions sc_time_stamp and sc_signal::read
Thei mplementati on is obl igedto keeptheobj ect returned fromfuncti onsc_time_stamp val id until thestart
of thenext ti med noti fi cati on phase.
Thei mplementati oni sobl iged to keeptheobject returnedfrom function sc_signal::read val id unti l theend
of thecurrent evaluation phase.
For both functions, it is strongly recommended that the appl icati on be written in such a way that it would
havei denti cal behavior, whether thesefuncti ons return areferenceto an object or return thesameobject by
val ue.
3.3.4 Namespaces and internal naming
An impl ementation shal l place every decl arati on specified by this standard, with the one excepti on of
sc_main, wi thin one of the fi ve namespaces sc_core, sc_dt, sc_unnamed, tlm, and tlm_utils. The core
languageand predefi ned channel sshall bepl aced in thenamespacesc_core. TheSystemC datatypes proper
shal l be pl aced in the namespace sc_dt. The SystemC utili ti es are di vi ded between the two namespaces
sc_coreand sc_dt.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


11
Copyright 2012 IEEE. All rights reserved.
It is recommended that an i mplementation use nested namespaces wi thin sc_core and sc_dt in order to
reduceto aminimumthenumber of impl ementati on-defined namesin thesetwo namespaces. Thenamesof
any such nested namespacesshall bei mplementati on-defi ned.
In general, the choi ce of internal, i mplementati on-specific names withi n an i mplementati on can cause
naming confl ictswi thin an appli cation. It i sup to thei mplementor tochoosenamesthat areunli kel y to cause
naming confl icts wi thin anappli cati on.
3.3.5 Non-compliant applications and errors
In the case where an appli cati on fai ls to meet an obl igati on imposed by this standard, the behavi or of the
SystemC impl ementation shall be undefi ned in general . When thi sresultsi n the violation of adiagnosable
rul eof theC++ standard, theC++ impl ementation wi ll issue adi agnosti c messagein conformancewi th the
C++ standard.
When this standard expli ci tl y statesthat thefail ureof an appl icati on to meet aspeci fi c obli gation i san err or
or a war ni ng, the SystemC impl ementation shall generate a diagnosti c message by call ing the functi on
sc_report_handler::report. In the case of an err or , the implementation shall call function report with a
severi ty of SC_ERROR. In the case of a warni ng, the i mplementati on shall call functi on report with a
severi ty of SC_WARNING.
An i mplementati on or an appli cati on may choose to suppress run-ti me error checki ng and di agnostic
messages because of considerations of efficiency or practicality. For exampl e, an appl ication may cal l
member function set_actionsof cl ass sc_report_handler to take no action for certain categori es of report.
An appl ication that fai lsto meet theobl igati onsimposed by thisstandard remai nsin error.
There are cases where this standard states expli ci tl y that a certai n behavior or resul t i s undefi ned. This
standard places no obl igations on theimpl ementation in such aci rcumstance. In particular, such a ci rcum-
stancemay or may not result in anerr or or awarni ng.
3.4 Notes and examples
Notes appear at the end of certain subclauses, designated by the uppercase word NOTE. Notes often
descri betheconsequences of rul es defi ned el sewherein thisstandard. Certai n subclausesi ncl udeexamples
consisti ngof fragments of C++ sourcecode. Such notesandexampl esareinformati veto hel p thereader but
arenot an official part of thi sstandard.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


12
Copyright 2012 IEEE. All rights reserved.
4. Elaboration and simulation semantics
An i mplementati on of the SystemC class l ibrary i ncl udes a publ ic shel l consi sting of those predefined
classes, functi ons, macros, and so forth that can beuseddirectl y by an appl ication. Such featuresaredefined
in Clause 5, Cl ause 6, Clause 7, and Clause 8 of thi s standard. An i mplementati on al so i ncl udes a pri vate
ker nel that i mplements thecorefuncti onali ty of theclass li brary. Theunderlyi ng semanti csof thekernel are
defined in this clause.
Theexecution of aSystemCappl ication consi sts of el aborati on foll owed by si mul ati on. Elaborati on resul ts
in thecreation of themodul e hi erar chy. Elaborati on i nvol ves the execution of appl ication code, the publ ic
shel l of the i mplementation (as menti oned i n the preceding paragraph), and the pri vate kernel of the
impl ementation. Simul ation i nvolves the execution of theschedul er, part of the kernel, whi ch i n turn may
executeprocesses within theappli cation.
In addition to providi ng support for el aboration and i mplementing the schedul er, the kernel may also
provide i mplementati on-speci fic functi onali ty beyond the scope of this standard. As an example of such
functi onali ty, the kernel may save the state of the module hi erarchy after elaborati on and run or restart
simul ation from that point, or it may support the graphi cal displ ay of state variables on-the-fly during
simul ation.
Thephasesof el aboration and si mulati onshal l runi n thefollowi ngsequence:
a) ElaborationConstruction of themodul ehi erarchy
b) ElaborationCallbacks to function before_end_of_elaboration
c) ElaborationCallbacks to function end_of_elaboration
d) SimulationCallbacks to function start_of_simulation
e) SimulationInitialization phase
f) SimulationEvaluation, update, delta notification, and ti med noti fi cation phases(repeated)
g) SimulationCallbacks to function end_of_simulation
h) SimulationDestruction of the module hierarchy
4.1 Elaboration
The pri mary purpose of el aboration is to create i nternal data structures within the kernel as required to
support thesemanti cs of simul ati on. During el aboration, theparts of themodule hi erarchy (modul es, ports,
pri mitivechannel s, andprocesses) arecreated, andportsand exports arebound to channel s.
Theacti ons statedi nthefoll owi ng subcl ausescan occur duri ng el aborati onand onl y duri ng elaborati on.
NOTE 1Because these actions can only occur during elaboration, SystemCdoesnot support thedynamic creation or
modification of themodulehierarchy during simulation, althoughit doessupport dynamic processes.
NOTE 2Other actions besides thoselisted below may occur during elaboration, provided that they do not contradict
any statement madeinthisstandard. For example, theobjectsof classsc_dt::sc_logicmay becreatedduring elaboration
and spawned processes may be created during elaboration, but the function notify of class sc_event cannot becalled
during elaboration.
4.1.1 Instantiation
Instances of thefollowi ng cl asses(or cl assesderi ved fromtheseclasses) may becreated during el aboration
and only during el aboration. Such i nstances shall not be deleted before the destructi on of the modul e
hierarchy at theend of simul ation.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


13
Copyright 2012 IEEE. All rights reserved.
sc_module (see5.2)
sc_port (see5.12)
sc_export (see5.13)
sc_pri m_channel (see5.15)
An impl ementation shall permit an appl ication to have zero or one top-l evel module and may permit more
than onetop-l evel module(see4.3.4.1 and4.3.5).
Instances of cl ass sc_module and cl ass sc_prim_channel may only be created wi thin a module or from
functi on sc_main (or a function cal led fromsc_main), or in the absenceof an sc_main (see 4.3.5), i n the
formof oneor moretop-l evel modul es. Instancesof cl ass sc_port and class sc_export can only becreated
wi thin a modul e. It shall be an error to i nstanti ate a modul e or primitive channel other than as descri bed
above, or to instanti ateaport or export other thanwi thi namodule.
Thei nstantiati on of a module al so i mpli es the construction of objectsof cl ass sc_module_name and cl ass
sc_sensi ti ve

(see5.4).
Al though these rul es al low for considerable flexi bil ity in i nstantiati ng the module hi erarchy, it is strongl y
recommended that, wherever possibl e, module, port, export, and primitive channel i nstances be data
members of a module or thei r addresses be stored in data members of a module. Moreover, the names of
thosedatamembersshoul d matchthestring namesof theinstanceswherever possi bl e.
NOTE 1The four classes sc_module, sc_port, sc_export, and sc_prim_channel are derived from acommon base
classsc_object, and thus, they havesomemember functionsin common (see5.16).
NOTE 2Objects of classes derived from sc_object but not derived fromoneof thesefour classes may beinstantiated
during elaboration or simulation, asmay objectsof user-defined classes.
Exampl e:
#include"systemc.h"
struct Mod: sc_modul e
{
SC_CTOR(Mod) { }
} ;
struct S
{
Mod m; // Unusual codi ng styl e- modul ei nstancewi thi nstruct
S(char* name_) : m(name_) { }
} ;
struct Top: sc_modul e // Fivei nstancesof moduleMod exi st within modul eTop.
{
Mod m1; // Recommended codi ng styl e
Mod *m2; // Recommended codi ng styl e
Ss1;
SC_CTOR(Top)
: m1("m1"), // m1.name() returns"top.m1"
s1("s1") // s1.m.name() returns"top.s1"
{
m2 = new Mod("m2"); // m2->name() returns"top.m2"
f();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


14
Copyright 2012 IEEE. All rights reserved.
S*s2 = new S("s2"); // s2->m.name() returns "top.s2"
}
void f() {
Mod *m3 = new Mod("m3"); // Unusual codi ngstyl e- not recommended
} // m3->name() returns"top.m3"
} ;
int sc_main(i nt argc, char* argv[])
{
Top top("top");
sc_start();
return 0;
}
4.1.2 Process macros
An unspawned pr ocess i nstance is aprocesscreatedby invoking oneof thefol lowing threeprocessmacros:
SC_METHOD
SC_THREAD
SC_CTHREAD
The name of a member function belongi ng to a cl ass derived fromclass sc_module shal l be passed as an
argument to the macro. Thi s member functi on shal l become the function associ ated wi th the process
instance.
Unspawnedprocessescan becreated during el aborati on or fromtheend_of_elaboration call back. Spawned
processes may becreatedby cal li ng thefuncti on sc_spawnduring elaboration or simul ation.
The purpose of the process macros i s to regi ster the associated functi on wi th the kernel such that the
schedul er can call back that member functi on duri ng simul ation. It is al so possibleto usespawned processes
for thi s samepurpose. Theprocess macros areprovided for backward compati bi li ty wi th earl ier versi onsof
SystemCand to providecl ockedthreads for hardwaresynthesi s.
4.1.3 Port binding and export binding
Port i nstances can be bound to channel instances, to other port i nstances, or to export i nstances. Export
instances can be bound to channel i nstances or to other export i nstances but not to port instances. Port
binding i s an asymmetri cal rel ationshi p, and export bi ndi ng i s an asymmetrical relationshi p. If a port is
bound to achannel , it is not trueto say that thechannel is bound to theport. Rather, it istrueto say that the
channel is thechannel to whi chtheport i sbound.
Portscan bebound by nameor by posi tion. Named port bi nding i sperformedby amember functi onof class
sc_port (see 5.12.7). Posi ti onal port binding i s performed by a member function of cl ass sc_module (see
5.2.19). Exports can onl y be bound by name. Export bi ndi ng is performed by a member functi on of class
sc_export (see5.13.7).
A given port instanceshall not bebound both by nameand by posi ti on.
A port shoul dtypi call y bebound wi thi ntheparent of themodul ei nstancecontaini ng that port. Hence, when
port A i s bound to port B, the modul e containing port A wi ll typical ly be i nstanti ated wi thi n the module
contai ning port B. An export shoul d typi cal ly be bound withi n the modul e containi ng the export. A port
should typi cal ly bebound to achannel or aport that li es wi thi nthesamemodul ein which theport i sbound
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


15
Copyright 2012 IEEE. All rights reserved.
or to an export withi n achi ld modul e. An export shoul d typi call y bebound to achannel that li eswithi n the
samemodulein which theexport i sboundor to an export wi thin achi ld module.
When port A is bound to port B, and port B isbound to channel C, theeffect shal l be thesameasi f port A
werebound directly to channel C. Wherever thi sstandardrefersto port A bei ng bound tochannel C, i t shal l
beassumed thismeansthat port A i sbound either directly to channel Cor to another port that isitself bound
to channel Caccordi ng tothis very samerule. Thi ssameruleshall apply whenbi ndi ng exports.
Port and export binding can occur during el aboration and onl y during el aboration. Whether a port need be
bound is dependent on theport pol icy argument of the port i nstance, whereas every export shal l be bound
exactl y once. A modul emay havezero or moreportsand zero or moreexports. If amodulehasno ports, no
(positional ) port bindings are necessary or permi tted for instancesof that module. Ports may be bound (by
name) i n any sequence. The bi ndi ng of ports belongi ng to di fferent modul e instances may be interleaved.
Sinceaport may bebound to another port that hasnot yet i tsel f been bound, thei mplementati on may defer
the completion of port binding unti l a later time duri ng el aboration, whereas exports shall be bound
immedi ately. Such deferred port binding shal l becompleted by the impl ementation beforethecall backs to
functi on end_of_elaboration.
Thechannel to which a port is bound shall not bedel eted before thedestruction of themodul ehierarchy at
theend of simul ation.
Where permi tted in thedefi niti on of theport object, asingleport can be bound to multi ple channel or port
instances. Such ports areknown asmul ti ports (see5.12.3). An export can onl y bebound once. It shall bean
error to bi nd agi ven port instanceto agiven channel instancemorethan once, even i f theport isamultiport.
When a port is bound to achannel, thekernel shall call the member function register_port of thechannel .
Thereisno corresponding functi on cal led when an export i sbound(see5.14).
Thepurposeof port and export binding isto enableaport or export to forward i nterfacemethod cal lsmade
during si mulation to thechannel instancesto whi ch that port wasbound during el aborati on. Thisforwarding
is performed duri ng simul ation by member functionsof the class sc_port and the cl ass sc_export, such as
operator->. A port r equi r es the servicesdefi ned by an interface (that is, the type of the port), whereas an
export provi des theservi ces definedby an i nterface(that is, thetypeof theexport).
NOTE 1A phrase such as bi nd a channel to a por t is not used in this standard. However, it is recognized that such a
phrasemay beusedinformally to meanbi nd a por t to a channel .
NOTE 2A port of a child module instance can be bound to an export of that samechild moduleinstance.
NOTE 3The member function register_port isdefined in theclasssc_interfacefromwhich every channel isderived.
4.1.4 Setting the time resolution
The si mulati on time resolution can be set duri ng elaboration and only duri ng el aboration. The time
resoluti oni sset by call ing thefunction sc_set_time_resolution (see5.11.3).
NOTETime resolution can only be set globally. Thereis no concept of alocal timeresolution.
4.2 Simulation
This subcl ause defines the behavi or of the schedul er and the semanti cs of simul ated ti me and process
executi on.
The primary purpose of the schedul er is to tri gger or resume the execution of the processes that the user
suppli es as part of the appli cation. The scheduler i s event-dri ven, meaning that processes are executed i n
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


16
Copyright 2012 IEEE. All rights reserved.
responseto theoccurrenceof events. Eventsoccur (arenoti fi ed) at preci sepoints in simul ation ti me. Events
arerepresented by obj ects of theclass sc_event, and by this cl ass al one(see5.10).
Simul ation time is an i nteger quantity. Simul ation time is initiali zed to zero at the start of simulati on and
increasesmonotonicall y during simul ati on. Thephysi cal significanceof theinteger val uerepresenti ng ti me
wi thin the kernel is determined by the si mulati on time resoluti on. Simul ation ti me and ti me i ntervals are
represented by class sc_time. Certain functions al low ti me to be expressed as a value pair having the
signaturedouble,sc_time_unit (see5.11.1).
The scheduler can execute a spawned or unspawned process i nstance as a consequence of one of the
fol lowi ng fivecauses, and theseal one:
In response to the process instance having been made runnabl e during the ini tial ization phase (see
4.2.1.1)
In response to a call to function sc_spawn during simulati on
In response to the occurrence of an event to whi ch theprocessi nstanceissensi ti ve
In response to a time-out having occurred
In response to a call to a process control member functi on of theclasssc_process_handle.
Thesensi ti vi ty of aprocess i nstanceisthe set of events and ti me-outs that can potentiall y causetheprocess
to be resumed or tri ggered. The stati c sensi ti vi ty of an unspawned process instance is fixed during
elaborati on. The stati c sensi ti vi ty of a spawned process i nstance is fixed when the function sc_spawn i s
cal led. The dynami c sensi ti vi ty of a process instance may vary over time under the control of the process
itsel f. A processi nstancei ssaid to besensi ti ve to an event i f theevent has beenadded to thestati c sensi ti vity
or dynami c sensi tivi ty of theprocessi nstance. A ti me-out occurswhenagiventimeinterval has elapsed.
Thescheduler shal l also manageevent notificati ons and pri mitivechannel updaterequests.
4.2.1 The scheduling algorithm
Thesemantics of thescheduli ng algori thm aredefi ned in the foll owing subcl auses. For the sakeof cl arity,
imperative l anguage i s used in this descri pti on. The descri pti on of the scheduli ng al gori thm uses the
fol lowi ng four sets:
The set of runnable processes
The set of update requests
The set of delta notifications and time-outs
The set of timed notifications and time-outs
An i mplementati on may substi tutean alternativescheme, provi ded thescheduli ng semanti cs given hereare
retai ned.
A processinstanceshal l not appear morethan oncei ntheset of runnableprocesses. An attempt to add to this
set aprocess instancethat i salready runnableshall bei gnored.
An update request results from, and only from, a cal l to member function request_update or
async_request_updateof classsc_prim_channel (see5.15.6).
An i mmedi ate noti fi cati on results from, and only from, acall to member functi on notify of class sc_event
wi th no arguments(see5.10.6).
A del ta noti fi cati on resul ts from, and only from, acal l to member functi on notify of cl ass sc_event with a
zero-valuedtimeargument.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


17
Copyright 2012 IEEE. All rights reserved.
A ti med noti fi cati on resul ts from, and onl y from, a call to member function notify of class sc_event with a
non-zero-valued time argument. Thetime argument determi nes the time of the notificati on, relati ve to the
ti mewhen functi onnotify is cal led.
A ti me-out resul ts from, and onl y from, certai n calls to functi ons wait or next_trigger, which aremember
functi ons of class sc_module, member functi ons of cl ass sc_prim_channel, and non-member functi ons. A
ti me-out resul ti ng fromacal l wi th azero-valued timeargument i sadded totheset of deltanotificationsand
ti me-outs. A time-out resulting fromacal l with anon-zero-valuedti meargument isadded to theset of ti med
noti fi cati ons and time-outs(see5.2.17and5.2.18).
Thescheduler starts by executing thei nitiali zati on phase.
4.2.1.1 Initialization phase
Performthefol lowi ng threestepsi ntheorder gi ven:
a) Run theupdatephaseasdefi ned in 4.2.1.3 but without conti nui ngto thedeltanoti fi cation phase.
b) Add every method and thread process i nstance in the obj ect hierarchy to the set of runnable
processes, but exclude those process i nstances for whi ch the functi on dont_initialize has been
cal led, and excludecl ocked thread processes.
c) Run thedeltanotificati on phase, asdefi ned i n 4.2.1.4. At theend of thedeltanotificati on phase, go
to theeval uation phase.
NOTEThe update and delta notification phases are necessary because update requests can be created during
elaboration in order to set initial valuesfor primitivechannels, for example, fromfunctioninitializeof classsc_inout.
4.2.1.2 Evaluation phase
Fromtheset of runnableprocesses, sel ect aprocessi nstance, removei t fromtheset, and onl y then trigger or
resumei tsexecuti on. Run theprocessi nstancei mmediately and without i nterruption up to thepoi nt whereit
either returnsor, i n thecaseof athreador cl ocked thread process, call sthefuncti on wait or call sthemember
functi on suspendof aprocesshandl eassociated wi th theprocessi nstancei tsel f.
Since process instances execute without i nterruption, onl y a si ngle process instance can berunni ng at any
one ti me, and no other process instance can execute until the currently executi ng process instance has
yielded control to thekernel . A processshal l not pre-empt or i nterrupt theexecution of another process. This
isknownasco-r outi ne semanticsor co-oper ati ve mul ti taski ng.
The order i n which process instances are sel ected from the set of runnabl e processes is impl ementation-
defined. However, if a specific versi on of a specific i mplementati on runs a specific appl ication usi ng a
specific input dataset, theorder of processexecution shall not vary from run to run.
A process may execute an immediate noti fi cati on, in which case all process i nstances that are currentl y
sensitiveto thenoti fi edevent shal l beaddedto theset of runnabl eprocesses. Such processinstancesshal l be
executed in thecurrent evaluation phase. Thecurrentl y executing processi nstanceshall not beadded to the
set of runnabl eprocessesas theresul t of an i mmediatenotification executed by theprocessinstanceitself.
A processmay cal l function sc_spawnto createaspawned processinstance, in whi ch casethenew process
instanceshall beaddedto theset of runnabl eprocesses(unlessfuncti on sc_spawn_options::dont_initialize
iscal led) andsubsequentl y executed in thi svery sameeval uation phase.
A processmay call themember functi on request_updateor async_request_updateof apri mitivechannel ,
which wi ll cause the member functi on update of that same pri mitive channel to be cal led back during the
very next updatephase.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


18
Copyright 2012 IEEE. All rights reserved.
A process may cal l aprocess control member function of the cl ass sc_process_handle, whi ch may causea
processinstanceto becomerunnabl ein thecurrent evaluati on phaseor may removeaprocessinstancefrom
theset of runnableprocesses.
Repeat thisstep unti l theset of runnableprocesses is empty; then goon to theupdatephase.
The scheduler is not pre-empti ve. An appl ication can assume that a method process wil l execute in its
entirety without interrupti on, and a thread or clocked thread process wi ll execute the code between two
consecutivecall stofunction wait wi thout interrupti on.
Because the order in which processes are run withi n the evaluati on phase is not under the control of the
appl ication, accessto shared storageshoul d beexpl icitly synchronizedtoavoid non-determi ni stic behavior.
An impl ementation runni ng on a machi ne that provi des hardware support for concurrent processes may
permi t two or more processes to run concurrently, provided that the behavior appears identical to the co-
routinesemantics defined i nthis subcl ause. In other words, thei mplementati onwould beobli ged toanal yze
any dependencies between processes and to constrain their execution to match theco-routinesemanti cs.
When an immediatenoti ficati onoccurs, onl y processesthat arecurrently sensiti vetothenotified event shal l
be made runnabl e. Thi s excludes processes that are only made dynami cal ly sensitive to the noti fied event
later i n thesameeval uation phase, unlessthoseprocesseshappen tobestati call y sensitiveto thegi ven event.
4.2.1.3 Update phase
Executeany and all pending cal ls to functi onupdateresulting fromcal ls to functi on request_updatemade
in theimmediatel y preceding evaluation phaseor madeduri ng elaborati onif theupdatephaseis executedas
part of the ini ti al ization phaseor resul ti ng fromcal ls to function async_request_update. Functi on update
shal l becall ed no morethanoncefor each primitivechannel i nstancei n eachupdatephase.
If no remaini ng pendi ng call s to functi on update exist, go on to the del ta noti fi cation phase(except when
executed from thei nitial ization phase).
4.2.1.4 Delta notification phase
If pendi ng delta noti fi cati ons or time-outs exist (whi ch can only result from cal ls to functi on notify or
functi on wait in theimmedi ately precedi ng evaluati on phaseor updatephase):
a) Determinewhichprocessinstancesaresensitiveto theseevents or ti me-outs.
b) Add al l such process instances totheset of runnabl eprocesses.
c) Removeall such noti fi cationsandtime-outsfromtheset of del tanotificationsand ti me-outs.
If, at the end of the del ta noti fi cati on phase, the set of runnabl e processes is non-empty, go back to the
eval uation phase.
4.2.1.5 Timed notification phase
If pending ti med notificationsor time-outsexist:
a) Advancesi mulati on timeto theti meof theearli est pendi ngtimed notificati on or time-out.
b) Determinewhi ch process i nstances aresensitiveto theevents notified and time-outs lapsi ng at thi s
precisetime.
c) Add al l such process instances totheset of runnabl eprocesses.
d) Removeall such noti fi cationsandtime-outsfromtheset of ti mednoti fi cati onsandtime-outs.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


19
Copyright 2012 IEEE. All rights reserved.
If no pendi ng timed notificati ons or time-outs exist, the end of simul ation has been reached. So, exi t the
schedul er.
If, at the end of the ti med noti fi cati on phase, the set of runnable processes is non-empty, go back to the
eval uation phase.
NOTEOn exiting the scheduler, the value of the simulation timewill depend on how thescheduler wasinvoked (see
4.3.4.2).
4.2.2 Initialization, cycles, and pauses in the scheduling algorithm
A del ta cycl e isasequenceof stepsin thescheduling al gori thmconsisti ngof thefoll owing stepsi ntheorder
given:
a) An evaluati onphase
b) An updatephase
c) A deltanoti fi cati on phase
Thei niti ali zati onphasedoesnot i ncl udeadel tacycle.
Update requests may be created duri ng el aborati on or before the i ni ti alizati on phase, and they shall be
schedul edto executei ntheupdatephaseduring theiniti ali zati onphase.
Delta notifi cati ons and timed notifications may be created during el aboration or before the ini ti al izati on
phase. Such delta noti fi cati ons shall be schedul ed to occur in the del ta notification phase during the
ini ti al izati on phase.
Thescheduler repeatedly executeswholedel tacycl esandmay ceaseexecution at theboundary between the
deltanotificati onandeval uation phases. Theonl y circumstancesin which thescheduler can ceaseexecution
other than at thi s boundary are after a call to functi on sc_stop, when an exception is thrown, or when
simul ation is stopped or aborted by thereport handler (see8.3).
When sc_pausei scal led, theschedul er shal l ceaseexecuti on at theend of adeltanoti fi cation phase, and if i t
isto resumeexecution, thescheduler shall resumeat thestart of thenext evaluati on phase.
An appl ication may create update requests and event notificati ons whil ethe schedul er is paused, and these
shal l be treated by the scheduler asi f they had been created in theevaluation phasei mmediately fol lowi ng
resumpti on, i n thefoll owing sense: updaterequestsshall bequeued to beexecuted i n thefirst updatephase
fol lowi ng resumpti on, immedi ate notifications shal l make any sensitive processes runnable in the fi rst
eval uation phase, and delta notificati ons shall make any sensitive processes runnabl e in the second
eval uation phasefol lowi ng resumpti on.
Update requests created before the i nitiali zati on phase or whi le the scheduler i s paused shal l not be
associ ated wi th any processi nstancewi th respect to therulesfor updating thestateof any primiti vechannel ,
for example, thewri ter poli cy of sc_signal.
NOTE 1The scheduling algorithmimplies theexistenceof three causal loops resulting fromimmediate notification,
deltanotification, and timed notification, asfollows:
The immediate notification loop isrestrictedto asingleevaluation phase.
The delta notification loop takes the path of an evaluation phase, followed by an updatephase, followed by a
deltanotification phase, and back to an evaluationphase. This loopadvancessimulationby onedeltacycle.
The timed notification loop takes thepath of an evaluation phase, followed by an updatephase, followed by a
delta notification phase, followed by a timed notification phase, and back to an evaluation phase. This loop
advancessimulationtime.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


20
Copyright 2012 IEEE. All rights reserved.
NOTE 2The immediate notification loop is non-deterministic in thesense that process execution can beinterleaved
withimmediatenotification, and theorder in which runnableprocessesareexecuted isundefined.
NOTE 3The delta notification and timed notification loops are deterministic in the sense that process execution
alternateswithprimitivechannel updates. If, within aparticular application, inter-processcommunication is confined to
using only deterministic primitivechannels, thebehavior of theapplication will beindependent of theorder in which the
processes areexecuted within theevaluation phase(assuming no other explicit dependencies on process order such as
external input or output exist).
4.3 Running elaboration and simulation
An impl ementation shal l provide ei ther or both of the foll owing two mechani sms for runni ng elaboration
and simul ation:
Under application control using functions sc_mainand sc_start
Under control of the kernel
Both mechanismsaredefined i n thefol lowi ng subclauses. An implementation is not obl igedtoprovideboth
mechanisms.
4.3.1 Function declarations
namespacesc_core{
int sc_elab_and_sim( i nt argc, char* argv[] );
int sc_argc();
const char* const* sc_argv();
enum sc_starvation_policy {
SC_RUN_TO_TIME,
SC_EXIT_ON_STARVATION
} ;
void sc_start();
void sc_start( const sc_ti me&, sc_starvation_pol icy p = SC_RUN_TO_TIME );
void sc_start( double, sc_time_unit, sc_starvation_pol icy p= SC_RUN_TO_TIME );
}
4.3.2 Function sc_elab_and_sim
Thefunction main that i s theentry point of theC++ programmay beprovi ded by theimpl ementation or by
the appli cati on. If function main is provided by the impl ementation, functi on main shall ini ti ate the
mechanisms for el aboration and si mulation as descri bed in thi s subcl ause. If functi on main is provided by
the appli cation, function main shall cal l the function sc_elab_and_sim, which i s the entry point i nto the
SystemCimpl ementation.
Thei mplementati onshall provi deafunction sc_elab_and_sim with thefoll owing declarati on:
int sc_elab_and_sim( i nt argc, char* argv[] );
Function sc_elab_and_sim shall i ni ti ate the mechanisms for runni ng el aboration and simulati on. The
appl icati on should pass the val ues of the parameters from functi on main as arguments to functi on
sc_elab_and_sim. Whether the appli cati on may cal l function sc_elab_and_sim more than once is
impl ementation-defined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


21
Copyright 2012 IEEE. All rights reserved.
A return value of 0 from function sc_elab_and_sim shall i ndi cate successful completi on. An
implementation may useother returnvaluesto i ndi cateother termi nation conditions.
NOTEFunction sc_elab_and_simwasnamed sc_main_mainin an earlier version of SystemC.
4.3.3 Functions sc_argc and sc_argv
Thei mplementati onshall provi defuncti ons sc_argcand sc_argv with thefoll owi ng declarati ons:
int sc_argc();
const char* const* sc_argv();
These two functions shal l return the values of the arguments passed to functi on main or functi on
sc_elab_and_sim.
4.3.4 Running under application control using functions sc_main and sc_start
The appli cation provides a function sc_main and call s the functi on sc_start, as defined i n 4.3.4.1 and
4.3.4.2.
4.3.4.1 Function sc_main
An appli cation shall provi de a function sc_main in the gl obal namespace wi th the foll owing declaration.
Theorder and typesof theargumentsand thereturn typeshal l beasshown here:
int sc_main( i nt argc, char* argv[] );
This function shall be call ed once from the kernel and is the only entry poi nt into the appli cation. The
argumentsargc and argv[] arecommand-l inearguments. Thei mplementati on may pass thevaluesof C++
command-li ne arguments (as passed to functi on main) through to function sc_main. The choice of which
C++ command-li neargumentsto passisimpl ementation-defi ned.
Elaborati on consi sts of the execution of the sc_main functi on from the start of sc_main to the point
immedi ately beforethefi rst cal l tothefuncti on sc_start.
A return value of 0 from function sc_main shall indicate successful compl eti on. An appl ication may use
other return val ues to indicateother terminati on condi ti ons.
NOTE 1As a consequence of the rules definedin 4.1, beforecalling function sc_start for thefirst time, thefunction
sc_main may instantiate modules, instantiate primitive channels, bind the ports and exports of module instances to
channels, and set thetimeresolution. Morethan onetop-level modulemay exist.
NOTE 2Throughout this standard, the termcal l is taken to mean call directly or indirectly. Hence, function sc_start
may becalled indirectly fromfunctionsc_mainby another function or functions.
4.3.4.2 Function sc_start
Theimpl ementation shal l provideafunction sc_start i n thenamespacesc_core, overl oadedwith thefoll ow-
ing signatures:
void sc_start();
void sc_start( const sc_ti me&, sc_starvation_pol icy p = SC_RUN_TO_TIME );
void sc_start( double, sc_time_unit, sc_starvation_pol icy p= SC_RUN_TO_TIME );
Thebehavi or of thelatter functi onshal l beequivalent to thefol lowi ng defi ni ti on:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


22
Copyright 2012 IEEE. All rights reserved.
void sc_start( doubled, sc_time_unit t, sc_starvation_policy p ) { sc_start( sc_time(d, t), p ); }
When called for the first ti me, functi on sc_start shall start the scheduler, which shall run up to the
simulation time passed as an argument (if an argument was passed), unless otherwise i nterrupted, and as
determi ned by the starvation pol icy argument. The scheduler shal l execute the initiali zation phase before
executi ng thefi rst eval uation phase, as described i n 4.2.1.1.
When call edon thesecond and subsequent occasions, function sc_start shal l resumethescheduler fromthe
ti meit had reached at theend of thepreviouscall to sc_start. Thescheduler shall run for thetimepassed as
an argument (i f an argument was passed), relati ve to the current simul ati on ti me, unless otherwise
interrupted, and as determi ned by the starvati on poli cy argument. The scheduler shal l execute from the
eval uation phaseof anew deltacycl e, as described in 4.2.2.
When a time is passed as an argument, the scheduler shal l execute up to and i ncl udi ng the l atest timed
notifi cati on phase with si mulati on time less than or equal to the end ti me (cal cul ated by adding the ti me
given as an argument to the si mulati on timewhen function sc_start is called). On return fromsc_start, if
theargument of typesc_starvation_policy hastheval ueSC_RUN_TO_TIME, theimpl ementation shall set
simul ation ti me equal to theend ti me, regardl ess of the ti me of the most recent event notificati on or ti me-
out. If the argument of type sc_starvation_policy has the val ue SC_EXIT_ON_STARVATION, the
impl ementation shal l set si mulati on timeequal to theti meof themost recent event noti fi cati on or time-out,
which may belessthan theend ti me.
When functi onsc_start i s cal led without any arguments, thescheduler shall run unti l therei s no remaining
activi ty, unl ess otherwi seinterrupted. In other words, except when sc_stop or sc_pausehavebeen called or
an excepti on has been thrown, control shall only be returned from sc_start when the set of runnable
processes, the set of update requests, the set of del ta noti fi cati ons and time-outs, and the set of timed
notifi cati ons and ti me-outs are al l empty. On return fromsc_start, thei mplementati on shal l set si mulati on
ti meequal tothetimeof themost recent event noti fi cation or ti me-out.
When function sc_start is call ed wi th a zero-valued time argument, the scheduler shal l run for one del ta
cycl e, that is, an evaluati on phase, an updatephase, and adel tanotification phase, in that order. Theval ueof
thestarvation poli cy argument shall beignored. Simul ation ti meshal l not beadvanced. If thisisthefi rst call
to sc_start, the scheduler shal l execute the initiali zation phase before executi ng the evaluation phase, as
descri bed i n 4.2.1.1. If, when sc_start i s cal led with a zero-valued ti me argument, the set of runnabl e
processes is empty, the set of update requests is empty, and the set of del ta noti fi cations and ti me-outs i s
empty; that i s, i f sc_pending_activity_at_current_time() == false, the i mplementati on shal l i ssue a
warni ng andthevaluereturned from sc_delta_count shal l not bei ncremented.
Oncestarted, thescheduler shall run unti l either i t reachestheend ti me, therei snoremai ning acti vi ty, or the
appl icati on call s thefuncti on sc_pauseor sc_stop, an exception occurs, or simulati on i sstopped or aborted
by the report handler (see 8.3). If the functi on sc_pause has been call ed, function sc_start may be call ed
agai n. Once the function sc_stop has been cal led, functi on sc_start shall not be cal led agai n. If nei ther
sc_pause nor sc_stop havebeen cal led, thei mplementati on shall i nsert an impl ici t cal l to sc_pause before
returning control fromfuncti on sc_start, and functi onsc_start may becal led again.
Updaterequests, timed notifications, and deltanotificati ons may becreated beforethefirst call to sc_start,
but immedi atenoti fi cations shal l not becreated before thefirst cal l to sc_start. Updaterequests and event
notifi cati ons, including immedi atenoti fi cations, may becreated between or after cal ls to sc_start.
Function sc_start may becal led from function sc_main, and only from function sc_main.
Appli cati ons arerecommended tocal l function sc_stop beforereturning control fromsc_mainto ensurethat
theend_of_simulation cal lbacks arecall ed (see4.4.4).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


23
Copyright 2012 IEEE. All rights reserved.
Exampl e:
int sc_main( i nt argc, char* argv[] )
{
Top top("top"); // Instanti atemodul ehi erarchy
sc_start(100, SC_NS); // Run for exactl y 100 ns
sc_start(); // Run unti l nomoreacti vity
if (sc_get_status() == SC_PAUSED) {
SC_REPORT_INFO("", "sc_stopcall ed to terminateapaused simulation");
sc_stop();
}
return 0;
}
NOTEWhen the scheduler is paused between successivecallsto function sc_start, theset of runnableprocesses does
not need to beempty.
4.3.5 Running under control of the kernel
Elaborati on and si mulati on may be initiated under the di rect control of the kernel, i n whi ch case the
impl ementation shall not cal l the function sc_main, and the i mplementati on is not obli ged to provide a
functi on sc_start.
An impl ementation may permit morethan onetop-level module, but i t i snot obli ged to do so.
Inthi scase, themechanismsused to i nitiateel aborati on andsi mulation and toi denti fy top-l evel modulesare
impl ementation-defined.
Inthi scase, ani mplementati on shall honor al l obligati onsset out in thi sstandard with theexcepti on of those
in 4.3.4.
4.4 Elaboration and simulation callbacks
Four call back functions are cal led by the kernel at vari ous stages during elaboration and si mulati on. They
havethefoll owing declarations:
virtual void before_end_of_elaboration();
virtual void end_of_elaboration();
virtual void start_of_simulation();
virtual void end_of_simulation();
The impl ementation shal l define each of these four call back functions as member functi ons of the cl asses
sc_module, sc_port, sc_export, and sc_prim_channel, and each of these definitions shall have empty
functi on bodi es. The i mplementati on also overri des various of these functions as member functi ons of
various predefi ned channel and port cl asses and having specific behavi ors (see Clause 6). An appli cati on
may overri de any of these four functions in any class deri ved from any of the cl asses menti oned in this
paragraph. If an appl ication overrides any such cal lback function of apredefined classand thecall back has
impl ementation-defined behavior (for exampl e, sc_in::end_of_elaboration), the appli cati on-defined
member function in thederi ved class may or may not call the impl ementation-defi ned functi on of the base
class, and thebehavior wi ll di ffer, dependi ng on whether themember functi onof thebaseclassiscal led.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


24
Copyright 2012 IEEE. All rights reserved.
Wi thi n each of the four categori es of call back functions, the order in which the cal lbacks are made for
objectsof cl asssc_module, sc_port, sc_export, and sc_prim_channel shall bei mplementati on-defined.
Theimpl ementation shall makecall backsto al l such functionsfor every instancein themodulehi erarchy, as
defined in thefoll owing subcl auses.
Thei mplementati on shal l providethefoll owing two functi ons:
namespacesc_core{
bool sc_start_of_simulation_invoked();
bool sc_end_of_simulation_invoked();
}
Function sc_start_of_simulation_invokedshall return trueafter and only after al l thecall backstofuncti on
start_of_simulation have executed to compl eti on. Function sc_end_of_simulation_invoked shal l return
trueafter, and onl y after, all thecall backstofunction end_of_simulation haveexecuted tocompleti on.
4.4.1 before_end_of_elaboration
The impl ementation shall make cal lbacks to member functi on before_end_of_elaboration after the
construction of themodulehierarchy definedi n 4.3 i scomplete. Functi on before_end_of_elaboration may
extend theconstruction of the modul ehi erarchy by i nstanti ating further modul es (and other obj ects) wi thi n
themodul ehi erarchy.
Thepurpose of member functi on before_end_of_elaboration is to all ow an appl icati on to perform acti ons
duri ng elaboration that depend on theglobal properti es of themodulehi erarchy and that al so need to modi fy
the modul e hierarchy. Examples incl ude the i nstantiati on of top-level modul es to moni tor events buried
wi thin thehi erarchy.
The foll owing acti ons may be performed directl y or indirectly from the member function
before_end_of_elaboration.
a) Thei nstantiati onof objects of class sc_module, sc_port, sc_export, sc_prim_channel.
b) Thei nstantiati on of obj ects of other classesderived fromclasssc_object.
c) Port bi ndi ng.
d) Export bi ndi ng.
e) Themacros SC_METHOD, SC_THREAD, SC_CTHREAD, and SC_HAS_PROCESS.
f) Themember sensitiveand member functi ons dont_initialize, set_stack_size, reset_signal_is, and
async_reset_signal_is, of theclasssc_module.
g) Call sto event fi nder functions.
h) Call sto function sc_spawnto createstatic, spawnedprocesses.
i ) Call s to member function set_sensitivity of cl ass sc_spawn_options to set the sensitivity of a
spawned process usi ng an event, an i nterface, or an event finder functi on. A port cannot be used
becauseport bi ndi ngmay havebeen deferred.
j ) Call s to member functions reset_signal_is and async_reset_signal_is of the class
sc_spawn_options.
k) Call stomember functionsrequest_updateor async_request_updateof classsc_prim_channel to
createupdaterequests (for exampl e, by call ing member functi on initializeof class sc_inout).
l ) Call s to member functi ons notify(const sc_time&) and notify(double,sc_time_unit) of class
sc_event to createdel taand ti mednoti fi cations.
m) Call s to the process control member functions suspend, resume, disable, enable, sync_reset_on,
andsync_reset_off of classsc_process_handle.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


25
Copyright 2012 IEEE. All rights reserved.
Thefoll owi ngconstructsshall not beused directl y or indirectly wi thin cal lback before_end_of_elaboration:
a) Call sto member functi on notify of classsc_event with an empty argument li st to createimmedi ate
noti ficati ons
b) Call stotheprocess control member functionskill, reset, or throw_it of classsc_process_handle
Thefol lowing constructs cannot beused directly withi n member function before_end_of_elaboration, but
they may be used where permitted wi thi n modul e instances nested within call backs to
before_end_of_elaboration:
a) ThemacroSC_CTOR
operator-> and operator[] of class sc_port shoul d not be cal led from the function
before_end_of_elaborationbecause the impl ementation may not havecompleted port bi ndi ng at thetime
of thi scall back and, hence, theseoperatorsmay returnnull pointers. Themember function sizemay return a
val uel ess thani tsfi nal value.
Any sc_object instances created fromcall back before_end_of_elaboration shall beplaced at a location i n
themodulehierarchy as i f thoseinstanceshad been createdfromtheconstructor of themodul eto which the
cal lback belongs, or to the parent modul ei f the call back bel ongs to aport, export, or primiti vechannel. In
other words, it shal l beasif theinstanceswerecreated fromtheconstructor of theobject whosecal lback is
cal led.
Objectsi nstantiated fromthemember function before_end_of_elaboration may themsel vesoverrideany of
the four call back functi ons, including the member functi on before_end_of_elaboration itsel f. The
impl ementation shall make all such nested call backs. An appl icati on can assume that every such member
functi onwi ll becal led back by theimpl ementation, whatever thecontext i nwhi ch theobj ect isinstantiated.
4.4.2 end_of_elaboration
Theimpl ementation shal l call member function end_of_elaboration at thevery end of el aboration after al l
cal lbacks to before_end_of_elaboration have completed and after the completion of any i nstantiati on or
port bi ndi ngperformed by thosecallbacksand beforestarting simul ation.
The purpose of member function end_of_elaboration i s to all ow an appl icati on to perform housekeepi ng
actions at theend of el aboration that do not need to modi fy themodul ehi erarchy. Exampl esi ncl udedesi gn
rul echecki ng, actions that depend on thenumber of timesaport isbound, and pri nting diagnostic messages
concerning themodul ehi erarchy.
Thefollowi ngacti ons may beperformed directly or i ndi rectl y fromthecal lback end_of_elaboration:
a) The instantiation of objects of classes derived from cl ass sc_object but excluding cl asses
sc_module, sc_port, sc_export, and sc_prim_channel
b) Themacros SC_METHOD, SC_THREAD, and SC_HAS_PROCESS
c) The member sensitive and member functi ons dont_initialize and set_stack_size of the cl ass
sc_module
d) Call sto function sc_spawnto createdynamic spawned processes
e) Call stomember functi onsrequest_updateor async_request_updateof classsc_prim_channel to
createupdaterequests (for exampl e, by call ing member functi on writeof classsc_inout)
f) Call s to member functi ons notify(const sc_time&) and notify(double,sc_time_unit) of class
sc_event to createdel taand ti mednoti fi cations
g) Call s to the process control member functions suspend, resume, disable, enable, sync_reset_on,
andsync_reset_off of classsc_process_handle
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


26
Copyright 2012 IEEE. All rights reserved.
h) Interfacemethod cal ls usi ng operator-> and operator[] of class sc_port, provided that thosecall s
do not attempt toperformactions prohibited outsidesi mulati onsuch asevent notification
Thefollowi ngconstructsshall not beused directl y or indirectly wi thin cal lback end_of_elaboration:
a) Thei nstantiati onof objects of class sc_module, sc_port, sc_export, sc_prim_channel
b) Port bi ndi ng
c) Export bindi ng
d) Themacros SC_CTOR, SC_CTHREAD
e) Themember functions reset_signal_isand async_reset_signal_isof theclasssc_module
f) Call stoevent fi nder functions
g) Call sto member functi on notify of classsc_event with an empty argument li st to createimmedi ate
noti ficati ons
h) Call stotheprocesscontrol member functionskill, reset, or throw_it of classsc_process_handle
4.4.3 start_of_simulation
The impl ementation shal l call member functi on start_of_simulation i mmediatel y when the appl ication
cal ls functi onsc_start for thefirst timeor at thevery start of simul ation, if simul ation i si nitiated under the
direct control of thekernel . If an appl icati on makesmultipl ecall stosc_start, theimpl ementation shall onl y
makethe cal lbacks to start_of_simulation on the fi rst such call to sc_start. The impl ementation shall call
functi on start_of_simulation after the cal lbacks to end_of_elaboration and before i nvoking the
ini ti al izati on phaseof thescheduler.
The purpose of member functi on start_of_simulation i s to all ow an appl ication to performhousekeeping
actions at the start of simul ation. Examples include opening sti mulus and response fil es and pri nting
diagnosti c messages. Theintenti on is that an i mplementati on that i ni ti atesel aborati on and simul ati on under
direct control of the kernel (in the absenceof functions sc_main and sc_start) shall make the cal lbacks to
end_of_elaboration at the end of el aborati on and the cal lbacks to start_of_simulation at the start of
simul ation.
Thefollowi ngacti onsmay beperformed directly or i ndi rectl y fromthecal lback start_of_simulation:
a) The instantiation of objects of classes derived from cl ass sc_object but excluding cl asses
sc_module, sc_port, sc_export, and sc_prim_channel
b) Call sto function sc_spawnto createdynamic spawned processes
c) Call stomember functi onsrequest_updateor async_request_updateof classsc_prim_channel to
createupdaterequests (for exampleby call ing member function writeof classsc_inout)
d) Call s to member functi ons notify(const sc_time&) and notify(double,sc_time_unit) of class
sc_event to createdel taand ti mednoti fi cations
e) Call s to the process control member functi ons suspend, resume, disable, enable, sync_reset_on,
andsync_reset_off of classsc_process_handle
f) Interfacemethod cal ls usi ng operator-> and operator[] of class sc_port, provided that thosecall s
do not attempt toperformactions prohibited outsidesi mulati onsuch asevent notification
Thefollowi ngconstructsshall not beuseddirectl y or indirectly wi thin cal lback start_of_simulation:
a) Thei nstantiati onof objects of class sc_module, sc_port, sc_export, sc_prim_channel
b) Port bi ndi ng
c) Export bindi ng
d) Themacros SC_CTOR, SC_METHOD, SC_THREAD, SC_CTHREAD, and SC_HAS_PROCESS
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


27
Copyright 2012 IEEE. All rights reserved.
e) Themember sensitiveand member functi ons dont_initialize, set_stack_size, reset_signal_is, and
async_reset_signal_isof theclass sc_module
f) Call stoevent fi nder functions
g) Call sto member functi on notify of cl ass sc_event with an empty argument li st to createimmedi ate
noti ficati ons
h) Call stotheprocess control member functionskill, reset, or throw_it of classsc_process_handle
4.4.4 end_of_simulation
The i mplementation shall call member function end_of_simulation at the point when the schedul er hal ts
because of the function sc_stop havi ng been call ed duri ng simul ati on (see 4.5.3) or at the very end of
simul ation if simul ation is ini ti atedunder thedirect control of thekernel . Theend_of_simulationcal lbacks
shal l only becal led onceeven if function sc_stop iscal led multipleti mes.
The purpose of member functi on end_of_simulation is to all ow an appl ication to perform housekeeping
actions at the end of simul ation. Exampl es i ncl ude closi ng stimul us and response fil es and printing
diagnosti c messages. Theintenti on isthat an i mplementati on that i ni ti atesel aborati on and simul ati on under
direct control of the kernel (in the absenceof functions sc_main and sc_start) shall make the cal lbacks to
end_of_simulationat thevery end of si mulation whether or not function sc_stop hasbeen cal led.
As a consequence of the language mechanisms of C++, the destructors of any obj ects in the module
hierarchy wil l be call ed as these objects are deleted at the end of program executi on. Any call backs to
functi on end_of_simulation shal l be made before the destructi on of the modul e hi erarchy. The function
sc_end_of_simulation_invoked may becal led by theappl ication withi n adestructor to determinewhether
thecal lback hasbeen made.
Theimpl ementation i snot obli ged to support any of thefoll owing actionswhen madedi rectl y or indirectl y
from the member functi on end_of_simulation or from the destructors of any objects i n the module
hierarchy. Whether any of theseactionscausesan error isimplementation-defined.
a) Thei nstantiati onof objects of classesderived fromclasssc_object
b) Call sto function sc_spawnto createdynamic spawned processes
c) Call stomember functi onsrequest_updateor async_request_updateof classsc_prim_channel to
createupdaterequests (for exampleby call ing member function writeof classsc_inout)
d) Call sto member function notify of theclass sc_event
4.5 Other functions related to the scheduler
4.5.1 Function declarations
namespacesc_core{
void sc_pause();
enum sc_stop_mode
{
SC_STOP_FINISH_DELTA ,
SC_STOP_IMMEDIATE
} ;
extern voi d sc_set_stop_mode( sc_stop_modemode);
extern sc_stop_modesc_get_stop_mode();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


28
Copyright 2012 IEEE. All rights reserved.
void sc_stop();
const sc_time& sc_time_stamp();
const sc_dt::ui nt64sc_delta_count();
bool sc_is_running();
bool sc_pending_activity_at_current_time();
bool sc_pending_activity_at_future_time();
bool sc_pending_activity();
sc_timesc_time_to_pending_activity();
enum sc_status
{
SC_ELABORATION = 0x01,
SC_BEFORE_END_OF_ELABORATION = 0x02,
SC_END_OF_ELABORATION = 0x04,
SC_START_OF_SIMULATION = 0x08,
SC_RUNNING = 0x10,
SC_PAUSED = 0x20,
SC_STOPPED = 0x40,
SC_END_OF_SIMULATION = 0x80
} ;
sc_statussc_get_status();
}
4.5.2 Function sc_pause
Thei mplementati onshall provi deafunction sc_pausewith thefoll owing declarati on:
void sc_pause();
Function sc_pauseshall causetheschedul er to ceaseexecution at theend of thecurrent del tacyclesuchthat
thescheduler canberesumed again later. If sc_start was call ed, sc_pauseshall causetheschedul er to return
control from sc_start at the end of the current del ta cycl e such that the schedul er can be resumed by a
subsequent cal l tosc_start.
Function sc_pauseshall benon-bl ocking; that i s, thecall ing function shal l continueto executeuntil i t yields
or returns.
If thefunction sc_pausei s cal led during theevaluati on phaseor theupdatephase, theschedul er shall com-
plete the current delta cycl e before ceasi ng execution; that is, the schedul er shall complete the eval uation
phase, theupdatephase, and thedel tanotificati on phase.
Function sc_pause may be call ed duri ng elaborati on, fromfuncti on sc_main, or fromone of the call backs
before_end_of_elaboration, end_of_elaboration, start_of_simulation, or end_of_simulation, i n whi ch
caseit shall haveno effect andshal l beignoredby theimpl ementation.
If sc_stop has al ready beencall ed, acall to sc_pauseshall haveno effect.
Thefol lowi ngoperati ons arepermitted whi lesimul ation is paused:
a) The i nstantiati on of objects of a type deri ved from sc_object provided that i nstanti ation of those
objectsi spermitted during simulati on
b) Call sto function sc_spawnto createdynami cprocesses
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


29
Copyright 2012 IEEE. All rights reserved.
c) Call sto member functi ons request_update and async_request_updateof cl ass sc_prim_channel
to createupdaterequests
d) Call sto member function notify of class sc_event to createimmedi ate, delta, or timed noti fi cations
e) Call s to the process control member functi ons suspend, resume, disable, enable, sync_reset_on,
andsync_reset_off of classsc_process_handle
f) Interfacemethod cal ls using operator-> and operator[] of cl ass sc_port, provi ded those functi ons
do not themsel vesperformany operationsthat areforbi dden whil esimul ation ispaused
g) Call sto function sc_stop
It shall bean error to perform any of thefol lowing operationswhilesimul ation ispaused:
a) Thei nstantiati onof objects of class sc_module, sc_port, sc_export, or sc_prim_channel
b) Port bi ndi ng
c) Export bindi ng
d) Invocation of themacrosSC_METHOD, SC_THREAD, or SC_CTHREAD
e) Useof themember sensitiveof classsc_moduleto createstatic sensiti vity
f) Call s to the member functi ons dont_initialize, set_stack_size, reset_signal_is, or
async_reset_signal_isof theclasssc_module
g) Call sto event fi nder functions
h) Call stotheprocess control member functions kill, reset, or throw_it of classsc_process_handle
i ) Call sto themember functi ons wait or next_trigger of cl asses sc_moduleandsc_prim_channel or
to thenon-member functi ons wait or next_trigger
4.5.3 Function sc_stop, sc_set_stop_mode, and sc_get_stop_mode
The impl ementation shall provide functions sc_set_stop_mode, sc_get_stop_mode, and sc_stop with the
fol lowi ng decl arations:
enum sc_stop_mode
{
SC_STOP_FINISH_DELTA ,
SC_STOP_IMMEDIATE
} ;
extern voi d sc_set_stop_mode( sc_stop_modemode);
extern sc_stop_modesc_get_stop_mode();
void sc_stop();
The functi on sc_set_stop_mode shall set the current stop mode to the val ue passed as an argument. The
functi on sc_get_stop_modeshall return thecurrent stop mode. Functi on sc_set_stop_mode may becall ed
during elaboration or from one of the cal lbacks before_end_of_elaboration, end_of_elaboration, or
start_of_simulation. If sc_set_stop_mode i s call ed more than once, the most recent call shal l take
precedence. It shal l bean error for theappl icati on to call functi on sc_set_stop_modefromthei nitiali zati on
phaseonward.
The function sc_stop may be cal led by the appl icati on from an elaborati on or si mulati on cal lback, froma
process, from the member functi on update of class sc_prim_channel, or from function sc_main. The
impl ementation may call thefunction sc_stop frommember functi onreport of class sc_report_handler.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


30
Copyright 2012 IEEE. All rights reserved.
A call to function sc_stop shall cause elaborati on or simulation to halt as descri bed bel ow and control to
return to function sc_main or to the kernel. The i mplementati on shal l pri nt out a message from function
sc_stop to standard output to indicate that si mulation has been halted by this means. The impl ementation
shal l maketheend_of_simulationcal lbacks asdescri bed in 4.4.4.
If the functi on sc_stop is cal led from one of the cal lbacks before_end_of_elaboration,
end_of_elaboration, start_of_simulation, or end_of_simulation, elaborati on or si mulati on shall hal t after
thecurrent call back phaseiscompl ete, that is, after al l cal lbacks of thegivenki nd havebeen made.
If thefuncti on sc_stop i s cal led duri ng theeval uation phaseor theupdatephase, theschedul er shall halt as
determi ned by thecurrent stop mode but i n any casebeforethe del tanoti fi cation phaseof thecurrent del ta
cycl e. If thecurrent stopmodeis SC_STOP_FINISH_DELTA, thescheduler shall completeboththecurrent
eval uation phase and the current update phase before halting simul ation. If the current stop mode is
SC_STOP_IMMEDIATE and functi on sc_stop i s call ed during the eval uation phase, the schedul er shal l
completetheexecution of thecurrent processand shall then halt wi thout executi ng any further processesand
wi thout executing theupdatephase. If functi onsc_stop iscall ed during theupdatephase, thescheduler shall
complete the update phase before hal ti ng. Whatever the stop mode, simul ation shal l not hal t until the
currentl y executi ng process has yi el ded control to the scheduler (such as by call ing function wait or by
executi ng areturnstatement).
Thedefault stopmodeshall beSC_STOP_FINISH_DELTA.
It shall bean error for theappl ication to cal l functi onsc_start after function sc_stop hasbeen cal led.
If functi on sc_stop is cal led a second time before or after el aboration or si mulati on has halted, the
implementation shal l issue a warning. If functi on stop_after of class sc_report_handler has been used to
cause sc_stop to be cal led on the occurrence of a warning, the i mplementati on shal l overri de this report-
handl ing mechani sm and shall not makefurther cal ls to sc_stop, preventing an infiniteregression.
A cal l tosc_stop shal l takeprecedenceover acal l to sc_pause.
NOTE 1A function sc_stop shall be provided by the implementation, whether or not the implementors choose to
provideafunctionsc_start.
NOTE 2Throughout this standard, the term cal l is taken to mean call directly or indirectly. Hence, function sc_stop
may becalled indirectly, for example, by an interfacemethod call.
4.5.4 Function sc_time_stamp
Thei mplementati onshall provi deafunction sc_time_stamp wi th thefoll owing declaration:
const sc_time& sc_time_stamp();
Thefuncti on sc_time_stamp shal l return thecurrent simul ati on ti me. Duri ng el aboration and ini ti al izati on,
thefuncti on shal l return avalueof zero.
NOTEThe simulation time can only bemodified by thescheduler.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


31
Copyright 2012 IEEE. All rights reserved.
4.5.5 Function sc_delta_count
The i mplementati on shall provi de a function sc_delta_count with the foll owing declaration:
const sc_dt::ui nt64 sc_delta_count();
The f unction sc_delta_count shal l return an i nteger val ue that is i ncremented exactl y once in each del ta
cycl e i n which at least one process is tri ggered or resumed and, thus, returns a count of the absolute number
of del ta cycles that have occurred duri ng si mulation, starting f rom zero, i gnoring any delta cycles i n whi ch
there were no runnabl e processes. The delta count shal l be 0 during elaboration, during the i ni ti al izati on
phase, and during the f irst evaluati on phase. The del ta count shal l f irst be incremented af ter the eval uation
phase of the fi rst whol e del ta cycl e. The delta count shal l be i ncremented between the evaluati on phase and
the update phase of each del ta cycle in which there were runnabl e processes.
A delta cycl e in which there are no runnabl e processes can occur when f uncti on sc_start is cal led wi th a
zero-valued time argument or when the schedul er is resumed foll owing a call to sc_pause.
When the schedul er i s resumed f ol lowi ng a call to f uncti on sc_pause, the delta count shal l conti nue to be
incremented as if sc_pausehad not been cal led.
When the delta count reaches the maxi mum val ue of type sc_dt::uint64, the count shal l start agai n f rom
zero. Hence, the delta count in successi ve delta cycl es mi ght be maxval ue-1, maxvalue, 0, 1, 2, and so on.
NOTEThis function is intended for use in primitive channel s to detect whether an event has occurred by comparing
the del ta count wi th the del ta count stored i n a vari abl e f rom an earl i er del ta cycle. The f ol lowi ng code f ragment wi ll test
whether a process has been executed i n two consecuti ve del ta cycl es:
if (sc_delta_count() == stored_delta_count + 1) { /* consecuti ve * / }
stored_del ta_count = sc_del ta_count();
4.5.6 Function sc_is_running
The i mplementati on shall provi de a function sc_is_runningwith the f oll owing decl aration:
bool sc_is_running();
The functi on sc_is_runningshall return the val ue true whi le the schedul er is runni ng or paused, incl udi ng
the initiali zation phase, and shall return the val ue false during el aboration, duri ng the call backs
start_of_simulation and end_of_simulation, and on return f rom sc_start after sc_stop has been cal led.
The f ol lowi ng rel ati on shal l hold:
sc_assert( sc_is_running() == (sc_get_status() & (SC_RUNNI NG | SC_PAUSED)) );
4.5.7 Functions to detect pending activity
The i mplementati on shal l provide four f unctions to detect pendi ng activi ty wi th the foll owing declarations:
bool sc_pending_activity_at_current_time();
bool sc_pending_activity_at_future_time();
bool sc_pending_activity();
sc_time sc_time_to_pending_activity();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


32
Copyright 2012 IEEE. All rights reserved.
The functi on sc_pending_activity_at_current_time shall return the value true if and only i f the set of
runnabl e processes is not empty, the set of update requests i s not empty, or the set of del ta notif icati ons and
ti me-outs i s not empty. By impl icati on, i f sc_pending_activity_at_current_time were to return the val ue
false, the next acti on of the scheduler would be to execute the timed notif icati on phase.
The f uncti on sc_pending_activity_at_future_timeshall return the value trueif and onl y i f the set of timed
notif i cati ons and ti me-outs is not empty.
The functi on sc_pending_activity shall return the val ue true if and onl y i f
sc_pending_activity_at_current_timeor sc_pending_activity_at_future_timewould return true.
The functi on sc_time_to_pending_activity shall return the ti me unti l the earl iest pendi ng activity,
cal cul ated as f oll ows.
If sc_pending_activity_at_current_time() == true, the val ue returned i s SC_ZERO_TIME.
Otherwise, if sc_pending_activity_at_future_time() == true, the value returned i s T -
sc_time_stamp(), where T is the ti me of the earli est ti med noti fi cati on or ti me-out in the set of
ti med notif ications and ti me-outs.
Otherwise, the value returned is sc_max_time() - sc_time_stamp().
These f our functi ons may be cal led at any ti me during or f ollowi ng el aborati on or si mulati on.
The functi on sc_pending_activity may return false at the end of el aboration. Theref ore, care shoul d be
taken when call ing sc_start in a loop condi ti onal on any of the f uncti ons that detect pending activity.
Exampl e:
int sc_main( i nt argc, char* argv[] )
{
// Instantiate top-level modul e
...
sc_start( SC_ZERO_TIME ); // Run the i ni ti al izati on phase to create pending acti vity
whil e( sc_pendi ng_activi ty() ) {
sc_start( sc_time_to_pending_activity() ); // Run up to the next acti vi ty
}
return 0;
}
4.5.8 Function sc_get_status
The i mplementati on shall provi de a function sc_get_statuswith the f oll owing declarati on:
sc_status sc_get_status();
The function sc_get_status shal l return one of the ei ght val ues of type sc_status to indicate the current
phase of el aboration or si mul ation as def ined by Tabl e 1.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


33
Copyright 2012 IEEE. All rights reserved.
When cal led f rom before_end_of_elaboration, the f unction sc_get_status shall return
SC_BEFORE_END_OF_ELABORATION even when call ed f rom a constructor (of a module or other
object) that is call ed di rectl y or indirectly f rom before_end_of_elaboration. I n other words, sc_get_status
permi ts the appli cation to disti ngui sh between the construction of the module hierarchy defi ned in 4.3 and
the extended constructi on of the module hierarchy def ined i n 4.4.1.
When sc_start is bei ng used, sc_get_statusshal l return SC_ELABORATION when called bef ore the f i rst
cal l to sc_start and shal l return ei ther SC_PAUSED or SC_STOPPED when call ed between or af ter call s to
sc_start.
If sc_pause and sc_stop have both been call ed, sc_get_statusshal l return SC_STOPPED.
When cal led from end_of_simulation, the f uncti on sc_get_status shal l return
SC_END_OF_SIMULATION i rrespective of whether sc_pauseor sc_stop have been call ed.
Exampl e:
if (sc_get_status() & (SC_RUNNI NG | SC_PAUSED | SC_STOPPED) )
...
Figure 1 shows the possible transi tions between the val ues of type sc_status as returned from functi on
sc_get_statuswhen call ed during the various phases of si mulati on.
NOTEWhen sc_start i s not bei ng used, the mechani sms f or runni ng el aborati on and simul ation are impl ementati on-
defi ned, as are the cal l backs to end_of_simulationi n the absence of a cal l to sc_stop(see 4.3 and 4.4.4).
Table 1Value returned by sc_get_status
Value Whencalled
SC_ELABORATI ON Duri ng the constructi on of the modul e hi erarchy, or i f sc_start
i s bei ng used, before the f i rst cal l to sc_start
SC_BEFORE_END_OF_ELABORATI ON From the cal l back f uncti on before_end_of_elaboration
SC_END_OF_ELABORATI ON Fromthe cal l back functi on end_of_elaboration
SC_START_OF_SI MULATION From the cal l back f uncti on start_of_simulation
SC_RUNNI NG From the i ni ti al ization, eval uati on, or update phase
SC_PAUSED When the scheduler is not runni ng and sc_pausehas been
cal l ed
SC_STOPPED When the scheduler is not runni ng and sc_stophas been cal led
SC_END_OF_SIMULATI ON From the cal l back f uncti on end_of_simulation
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


34
Copyright 2012 IEEE. All rights reserved.
Figure 1Transitions between values returned by sc_get_status
SC_ELABORATION
SC_BEFORE_END_OF_ELABORATION
SC_END_OF_ELABORATION
SC_START_OF_SIMULATION
SC_RUNNI NG SC_PAUSED
SC_END_OF_SIMULATI ON
SC_STOPPED
sc_start
(Cal lbacks)
sc_stop
Starvati on
Implementation-def ined
sc_pause
(Cal lbacks)
(Cal lbacks)
sc_start
sc_stop
Starvati on
(Cal lbacks)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


35
Copyright 2012 IEEE. All rights reserved.
5. Core language class definitions
5.1 Class header files
To use the SystemC cl ass library features, an appli cation shall i ncl ude ei ther of the C++ header fi les
specif ied i n this subclause at appropriate positions i n the source code as requi red by the scope and l inkage
rul es of C++. The TLM-1 and TLM-2.0 classes and TLM-2.0 util ities are i n separate header fi les (see 10.8).
5.1.1 #include "systemc"
The header f il e named systemc shal l add the names sc_core, sc_dt, and sc_unnamed to the declarative
region in whi ch it i s included, and these three names only. The header f il e systemcshall not introduce into
the decl arative region in which it i s included any other names from this standard or any names from the
standard C or C++ l ibraries.
I t is recommended that appl ications include the header f il e systemcrather than the header fi le systemc.h.
Exampl e:
#include "systemc"
usi ng sc_core::sc_module;
usi ng sc_core::sc_signal ;
usi ng sc_core::SC_NS;
usi ng sc_core::sc_start;
usi ng sc_dt::sc_logic;
#include <i ostream>
usi ng std::ofstream;
usi ng std::cout;
usi ng std::endl ;
5.1.2 #include "systemc.h"
The header fi le named systemc.h shall add all of the names f rom the namespaces sc_core and sc_dt to the
decl arative region in which i t i s i ncl uded, together with the name sc_unnamed and sel ected names f rom the
standard C or C++ l ibraries as defi ned in thi s subclause. I t is recommended that an i mplementati on keep to a
mi nimum the number of addi ti onal i mplementati on-specifi c names i ntroduced by this header f ile.
The header f il e systemc.h is provi ded f or backward compati bi li ty with earl ier versions of SystemC and may
be deprecated i n f uture versions of this standard.
The header f il e systemc.h shall include at least the f ol lowi ng:
#include "systemc"
// Using declarati ons for al l the names in the sc_core namespace speci fi ed i n this standard
usi ng sc_core::sc_module;
...
// Using declarati ons for al l the names in the sc_dt namespace specif ied in this standard
usi ng sc_dt::sc_int;
...
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


36
Copyright 2012 IEEE. All rights reserved.
// Using declarati ons for selected names in the standard li brari es
usi ng std::i os;
usi ng std::streambuf;
usi ng std::streampos;
usi ng std::streamsize;
usi ng std::i ostream;
usi ng std::i stream;
usi ng std::ostream;
usi ng std::cin;
usi ng std::cout;
usi ng std::cerr;
usi ng std::endl ;
usi ng std::fl ush;
usi ng std::dec;
usi ng std::hex;
usi ng std::oct;
usi ng std::f stream;
usi ng std::i fstream;
usi ng std::ofstream;
usi ng std::size_t;
usi ng std::memchr;
usi ng std::memcmp;
usi ng std::memcpy;
usi ng std::memmove;
usi ng std::memset;
usi ng std::strcat;
usi ng std::strncat;
usi ng std::strchr;
usi ng std::strrchr;
usi ng std::strcmp;
usi ng std::strncmp;
usi ng std::strcpy;
usi ng std::strncpy;
usi ng std::strcspn;
usi ng std::strspn;
usi ng std::strlen;
usi ng std::strpbrk;
usi ng std::strstr;
usi ng std::strtok;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


37
Copyright 2012 IEEE. All rights reserved.
5.2 sc_module
5.2.1 Description
Cl ass sc_module is the base cl ass for modules. Modul es are the pri nci pl e structural buil ding blocks of
SystemC.
5.2.2 Class definition
namespace sc_core {
class sc_bi nd_proxy

{ i mpl ementati on-defi ned } ;


const sc_bi nd_proxy

SC_BIND_PROXY_NIL;
class sc_module
: publi c sc_object
{
publ ic:
virtual ~sc_module();
virtual const char* kind() const;
void operator() ( const sc_bi nd_proxy

& p001,
const sc_bi nd_proxy

& p002 = SC_BIND_PROXY_NIL,


const sc_bi nd_proxy

& p003 = SC_BIND_PROXY_NIL,


...
const sc_bi nd_proxy

& p063 = SC_BIND_PROXY_NIL,


const sc_bi nd_proxy

& p064 = SC_BIND_PROXY_NIL );


virtual const std::vector<sc_object* >& get_child_objects() const;
virtual const std::vector<sc_event* >& get_child_events() const;
protected:
sc_module( const sc_modul e_name& );
sc_module();
void reset_signal_is( const sc_in<bool >& , bool );
void reset_signal_is( const sc_inout<bool >& , bool );
void reset_signal_is( const sc_out<bool >& , bool );
void reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
void async_reset_signal_is( const sc_in<bool >& , bool );
void async_reset_signal_is( const sc_inout<bool >& , bool );
void async_reset_signal_is( const sc_out<bool >& , bool );
void async_reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
sc_sensi ti ve

sensitive;
void dont_initialize();
void set_stack_size( si ze_t );
void next_trigger();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


38
Copyright 2012 IEEE. All rights reserved.
void next_trigger( const sc_event& );
void next_trigger( const sc_event_or_li st & );
void next_trigger( const sc_event_and_li st & );
void next_trigger( const sc_ti me& );
void next_trigger( double , sc_ti me_unit );
void next_trigger( const sc_ti me& , const sc_event& );
void next_trigger( double , sc_ti me_unit , const sc_event& );
void next_trigger( const sc_ti me& , const sc_event_or_l ist &);
void next_trigger( double , sc_ti me_unit , const sc_event_or_li st & );
void next_trigger( const sc_ti me& , const sc_event_and_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_and_li st & );
void wait();
void wait( i nt );
void wait( const sc_event& );
void wait( const sc_event_or_l ist &);
void wait( const sc_event_and_l ist & );
void wait( const sc_ti me& );
void wait( double , sc_time_unit );
void wait( const sc_ti me& , const sc_event& );
void wait( double , sc_time_unit , const sc_event& );
void wait( const sc_ti me& , const sc_event_or_l ist & );
void wait( double , sc_time_unit , const sc_event_or_l ist & );
void wait( const sc_ti me& , const sc_event_and_l ist & );
void wait( double , sc_time_unit , const sc_event_and_l ist & );
virtual void before_end_of_elaboration();
virtual void end_of_elaboration();
virtual void start_of_simulation();
virtual void end_of_simulation();
pri vate:
// Di sabl ed
sc_module( const sc_modul e& );
sc_module& operator= ( const sc_modul e& );
} ;
void next_trigger();
void next_trigger( const sc_event& );
void next_trigger( const sc_event_or_li st & );
void next_trigger( const sc_event_and_li st & );
void next_trigger( const sc_ti me& );
void next_trigger( double , sc_ti me_unit );
void next_trigger( const sc_ti me& , const sc_event& );
void next_trigger( double , sc_ti me_unit , const sc_event& );
void next_trigger( const sc_ti me& , const sc_event_or_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_or_li st & );
void next_trigger( const sc_ti me& , const sc_event_and_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_and_li st & );
void wait();
void wait( i nt );
void wait( const sc_event& );
void wait( const sc_event_or_l ist & );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


39
Copyright 2012 IEEE. All rights reserved.
void wait( const sc_event_and_li st & );
void wait( const sc_ti me& );
void wait( double , sc_time_unit );
void wait( const sc_ti me& , const sc_event& );
void wait( double , sc_time_unit , const sc_event& );
void wait( const sc_ti me& , const sc_event_or_l ist & );
void wait( double , sc_time_unit , const sc_event_or_l ist & );
void wait( const sc_ti me& , const sc_event_and_l ist & );
void wait( double , sc_time_unit , const sc_event_and_l ist & );
#def ine SC_MODULE(name) struct name : sc_module
#def ine SC_CTOR(name) i mpl ementati on-defi ned; name(sc_module_name)
#def ine SC_HAS_PROCESS(name) i mpl ementati on-defi ned
#def ine SC_METHOD(name) i mpl ementati on-defi ned
#def ine SC_THREAD(name) i mpl ementati on-defi ned
#def ine SC_CTHREAD(name,cl k) i mpl ementati on-defi ned
const char* sc_gen_unique_name( const char* );
typedef sc_modul e sc_behavior;
typedef sc_modul e sc_channel;
} // namespace sc_core
5.2.3 Constraints on usage
Objects of class sc_module can only be constructed during el aboration. It shall be an error to i nstantiate a
module during si mulati on.
Every class derived (di rectl y or indirectly) from cl ass sc_module shall have at l east one constructor. Every
such constructor shall have one and only one parameter of class sc_module_name but may have f urther
parameters of classes other than sc_module_name. That parameter is not required to be the fi rst parameter
of the constructor.
A stri ng-val ued argument shall be passed to the constructor of every module i nstance. It is good practi ce to
make this stri ng name the same as the C++ variabl e name through whi ch the module is ref erenced, i f such a
vari abl e exists.
I nter-modul e communication should typi call y be accompli shed usi ng i nterf ace method cal ls; that i s, a
module shoul d communicate with its envi ronment through i ts ports. Other communicati on mechanisms are
permi ssibl e, for example, for debuggi ng or di agnostic purposes.
NOTE 1Because the constructors are protected, cl ass sc_modulecannot be i nstantiated di rectl y but may be used as a
base class.
NOTE 2A module should be publ i cl y deri ved f rom cl ass sc_module.
NOTE 3It is permissibl e to use cl ass sc_module as an i ndi rect base cl ass. I n other words, a module can be deri ved
f rom another modul e. Thi s can be a usef ul codi ng i di om.
5.2.4 kind
Member f uncti on kind shall return the string "sc_module".
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


40
Copyright 2012 IEEE. All rights reserved.
5.2.5 SC_MODULE
The macro SC_MODULE may be used to prefi x the def ini tion of a modul e, but the use of this macro i s not
obligatory.
Exampl e:
// The f ollowi ng two cl ass defi nitions are equall y acceptabl e.
SC_MODULE(M)
{
M(sc_module_name) { }
...
} ;
class M: publ ic sc_modul e
{
publ ic:
M(sc_module_name) { }
...
} ;
5.2.6 Constructors
sc_module( const sc_modul e_name& );
sc_module();
Module names are managed by class sc_module_name, not by class sc_module. The stri ng name of the
module instance i s i nitiali zed usi ng the value of the string name passed as an argument to the constructor of
the class sc_module_name(see 5.3).
5.2.7 SC_CTOR
This macro i s provided f or convenience when declari ng or defi ning a constructor of a modul e. Macro
SC_CTOR shal l onl y be used at a place where the rul es of C++ permi t a constructor to be decl ared and can
be used as the decl arator of a constructor declaration or a constructor def ini tion. The name of the modul e
class bei ng constructed shall be passed as the argument to the macro.
Exampl e:
SC_MODULE(M1)
{
SC_CTOR(M1) // Constructor defini ti on
: i (0)
{ }
int i;
...
} ;
SC_MODULE(M2)
{
SC_CTOR(M2); // Constructor decl arati on
int i;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


41
Copyright 2012 IEEE. All rights reserved.
...
} ;
M2::M2(sc_modul e_name) : i(0) { }
The use of macro SC_CTOR i s not obl igatory. Using SC_CTOR, it i s not possible to add user-def ined
arguments to the constructor. I f an appl ication needs to pass addi ti onal arguments, the constructor shal l be
provided expli ci tl y. This is a useful coding i diom.
NOTE 1The macros SC_CTOR and SC_MODULE may be used i n conj uncti on or may be used separatel y.
NOTE 2Since macro SC_CTOR is equi val ent to decl aring a constructor f or a modul e, an i mpl ementati on wi l l ensure
that the constructor so decl ared has a parameter of type sc_module_name.
NOTE 3If process macros are invoked but macro SC_CTOR i s not used, macro SC_HAS_PROCESS shoul d be used
i nstead (see 5.2.8).
Exampl e:
SC_MODULE(M)
{
M(sc_module_name n, int a, int b) // Additional constructor parameters
: sc_modul e(n)
{ }
...
} ;
5.2.8 SC_HAS_PROCESS
Macro SC_CTOR includes defi nitions used by the macros SC_METHOD, SC_THREAD and
SC_CTHREAD. These same def ini ti ons are introduced by the macro SC_HAS_PROCESS. I f a process
macro i s invoked from the constructor body of a module but macro SC_CTOR i s not used within the modul e
class def ini tion, macro SC_HAS_PROCESS shall be invoked within the cl ass def inition or the constructor
body of the modul e. I f a process macro i s i nvoked from the before_end_of_elaboration or
end_of_elaboration cal lbacks of a module but macro SC_CTOR is not used wi thi n the module cl ass
def ini ti on, macro SC_HAS_PROCESS shall be invoked wi thin the class defi ni ti on of the modul e or f rom
that same call back.
Macro SC_HAS_PROCESS shal l onl y be used wi thin the class def ini tion, constructor body, or member
f uncti on body of a module. The name of the module class bei ng constructed shal l be passed as the argument
to the macro. The macro invocati on shal l be termi nated wi th a semicolon.
NOTEThe use of the macros SC_CTOR and SC_HAS_PROCESS is not requi red i n order to call the f uncti on
sc_spawn.
Exampl e:
SC_MODULE(M)
{
M(sc_module_name n) // SC_CTOR not used
: sc_modul e(n)
{
SC_THREAD(T); // Process macro
}
void T();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


42
Copyright 2012 IEEE. All rights reserved.

SC_HAS_PROCESS(M); // Necessary
...
} ;
5.2.9 SC_METHOD, SC_THREAD, SC_CTHREAD
The argument passed to the macro SC_METHOD or SC_THREAD or the fi rst argument passed to
SC_CTHREAD shal l be the name of a member f uncti on. The macro shall associ ate that f unction with a
method pr ocess i nstance, a thr ead process i nstance, or a cl ocked thr ead process i nstance, respecti vel y. Thi s
shall be the only way i n whi ch an unspawned process i nstance can be created (see 4.1.2).
The second argument passed to the macro SC_CTHREAD shall be an expression of the type
sc_event_finder.
I n each case, the macro i nvocati on shall be termi nated with a semi col on.
These three macros shal l only be invoked i n the body of the constructor, in the before_end_of_elaboration
or end_of_elaboration call backs of a module, or i n a member f uncti on cal led from the constructor or
cal lback. Macro SC_CTHREAD shal l not be invoked from the end_of_elaboration call back. The f irst
argument shal l be the name of a member f unction of that same module.
A member f unction associated with an unspawned process instance shal l have a return type of void and shall
have no arguments. (Note that a f uncti on associated with a spawned process i nstance may have a return type
and may have arguments.)
A si ngl e member function can be associated wi th multiple process instances withi n the same module. Each
process i nstance is a di stinct obj ect of a class derived f rom cl ass sc_object, and each macro shall use the
member f unction name (i n quotati on marks) as the string name ultimately passed as an argument to the
constructor of the base class sub-obj ect of class sc_object. Each process instance can have i ts own stati c
sensitivity and shall be triggered or resumed independently of other process instances.
Associati ng a member f unction with a process instance does not impose any expli ci t restricti ons on how that
member function may be used by the applicati on. For exampl e, such a function may be cal led di rectly by the
appl ication, as well as by the kernel.
A process i nstance can be suspended, resumed, disabled, enabl ed, kil led, or reset using the member
f uncti ons of class sc_process_handle.
Exampl e:
SC_MODULE(M)
{
sc_i n<bool> clk;
SC_CTOR(M)
{
SC_METHOD(a_method);
SC_THREAD(a_thread);
SC_CTHREAD(a_cthread, cl k.pos());
}
void a_method();
void a_thread();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


43
Copyright 2012 IEEE. All rights reserved.
void a_cthread();
...
} ;
5.2.10 Method process
This subclause shall apply to both spawned and unspawned process instances.
A method process is sai d to be tr i ggered when the kernel cal ls the f uncti on associ ated with the process
instance. When a method process is triggered, the associated f uncti on executes from begi nni ng to end, then
returns control to the kernel . A method process can only be ter mi nated by cal li ng the kill method of a
process handle associ ated wi th that process.
A method process i nstance may have stati c sensi ti vity. A method process, and only a method process, may
cal l the f unction next_trigger to create dynami c sensi ti vi ty. Function next_trigger i s a member f unction of
class sc_module, a member f unction of cl ass sc_prim_channel, and a non-member function.
A method process instance cannot be made runnabl e as a result of an immedi ate noti fi cati on executed by the
process i tself, regardl ess of the static sensi ti vi ty or dynamic sensi ti vity of the method process i nstance (see
4.2.1.2).
An implementati on i s not obli ged to run a method process i n a separate sof tware thread. A method process
may run in the same execution context as the si mulati on kernel.
Member function kind of the impl ementation-def ined class associated wi th a method process instance shal l
return the string sc_method_process.
NOTE 1Any local variables declared withi n the process wi ll be destroyed on return f rom the process. Data members
of the modul e shoul d be used to store persi stent state associ ated wi th the method process.
NOTE 2Function next_trigger can becal l ed f rom a member f uncti on of the modul e i tsel f , f rom a member f uncti on of
a channel , or f rom any f uncti on subj ect onl y to the rul es of C++, provi ded that the f uncti on i s ul timatel y cal l ed f rom a
method process.
5.2.11 Thread and clocked thread processes
This subclause shall apply to both spawned and unspawned process instances.
A f uncti on associated with a thread or cl ocked thread process i nstance is cal led once and onl y once by the
kernel, except when a process is reset; in which case, the associ ated f unction may be cal led again (see
5.2.12).
A thread or cl ocked thread process, and only such a process, may cal l the f uncti on wait. Such a call causes
the call ing process to suspend execution. Function wait is a member f unction of class sc_module, a member
f uncti on of cl ass sc_prim_channel, and a non-member function.
A thread or clocked thread process i nstance is said to be r esumed when the kernel causes the process to
continue execution, starti ng wi th the statement i mmediately f oll owing the most recent call to f unction wait.
When a thread or cl ocked thread process is resumed, the process executes unti l it reaches the next cal l to
functi on wait. Then, the process i s suspended once again.
A thread process i nstance may have static sensiti vity. A thread process instance may call functi on wait to
create dynami c sensitivity. A cl ocked thread process i nstance i s stati cal ly sensitive onl y to a si ngle cl ock.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


44
Copyright 2012 IEEE. All rights reserved.
A thread or clocked thread process i nstance cannot be made runnabl e as a result of an immedi ate noti fi cation
executed by the process i tsel f, regardl ess of the stati c sensi ti vity or dynami c sensi tivi ty of the thread process
instance (see 4.2.1.2).
Each thread or clocked thread process requi res i ts own executi on stack. As a result, context switchi ng
between thread processes may i mpose a simul ati on overhead when compared with method processes.
I f the thread or clocked thread process executes the enti re f uncti on body or executes a return statement and
thus returns control to the kernel , the associ ated functi on shall not be called again f or that process i nstance.
The process instance i s then said to be ter mi nated.
Member f uncti on kind of the i mplementati on-def ined cl ass associ ated with a thread process instance shall
return the string sc_thread_process.
Member f uncti on kind of the impl ementation-defined cl ass associated with a clocked thread process
instance shal l return the stri ng sc_cthread_process.
NOTE 1It is a common coding idiomto include an i nf i ni te l oop contai ni ng a cal l to f uncti on wait wi thi n a thread or
cl ocked thread process i n order to prevent the process f rom termi nati ng prematurel y.
NOTE 2When a process instance is resumed, any local variables defined within the process will retain the values they
had when the process was suspended.
NOTE 3If a thread or clocked thread process executes an infinite l oop that does not cal l f uncti on wait, the process wi l l
never suspend. Si nce the schedul er i s not pre-empti ve, no other process wi l l be abl e to execute.
NOTE 4Function wait can be cal l ed f rom a member f uncti on of the modul e i tself , f rom a member f uncti on of a
channel , or from any f uncti on subj ect onl y to the rul es of C++, provi ded that the f unction i s ul ti matel y call ed f rom a
thread or cl ocked thread process.
Exampl e:
SC_MODULE(synchronous_modul e)
{
sc_i n<bool> clock;
SC_CTOR(synchronous_module)
{
SC_THREAD(thread);
sensitive << cl ock.pos();
}
void thread() // Member functi on called once onl y
{
for (;;)
{
wait(); // Resume on positive edge of cl ock
...
}
}
...
} ;
5.2.12 Clocked thread processes
A clocked thread process shal l be a stati c process; clocked threads cannot be spawned processes.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


45
Copyright 2012 IEEE. All rights reserved.
A clocked thread process shall be stati call y sensitive to a si ngle cl ock, as determi ned by the event fi nder
passed as the second argument to macro SC_CTHREAD. The clocked thread process shal l be staticall y
sensitive to the event returned from the given event fi nder.
A clocked thread process may cal l either of the f ollowi ng f unctions:
void wait();
void wait( i nt );
It shall be an error f or a clocked thread process to call any other overloaded form of the functi on wait.
A cl ocked thread process may have any number of synchronous and asynchronous reset signal s specif ied
usi ng reset_signal_isand async_reset_signal_is, respecti vel y.
Any of the process control member functions of class sc_process_handlemay be cal led f or a cl ocked thread
process, although certain caveats apply to the use of member f uncti ons suspend, resume, reset, and
throw_it due to the f act that they can be cal led asynchronousl y with respect to the clock. These caveats are
descri bed bel ow.
I t is recommended to call disableand enablerather than suspend and resumefor cl ocked thread processes.
I n the case that resumeis call ed for a cl ocked thread process, i t is the responsibi lity of the cal ler to ensure
that resume i s cal led duri ng the eval uation phase that immediately fol lows the delta notif icati on or timed
noti fi cati on phase in which the clock event noti fi cati on occurs. If a cl ocked thread i s resumed at any other
ti me, that is, if the cal l to resumei s not synchroni zed wi th the cl ock, the behavior shall be impl ementation-
def ined.
The process control member f unctions kill, reset, and throw_it may be call ed asynchronousl y wi th respect
to the clock and thei r ef fect i s immediate, even in the case of a clocked thread process. Si mil arly, the ef fect
of an asynchronous reset attai ni ng i ts active value is immedi ate f or a cl ocked thread process.
I n summary, a cl ocked thread process shall have exactl y one cl ock signal and may have any number of
synchronous and asynchronous reset signal s as well as bei ng reset by call ing the process control member
f uncti on of cl ass sc_process_handle. As a consequence, the body of the associated functi on shoul d
normall y consist of reset behavi or f oll owed by a l oop statement that contains a cal l to wait f oll owed by the
behavior to be executed i n each cl ock cycl e (see the example below).
The fi rst time the clock event i s notif ied, the f unction associ ated with a clocked thread process shall be
cal led whether or not the reset signal is active. If a clocked thread process instance has been terminated, the
clock event shall be ignored for that process i nstance. A terminated process cannot be reset.
Exampl e:
sc_i n<bool> clock;
sc_i n<bool> reset;
sc_i n<bool> async_reset;
SC_CTOR(M)
{
SC_CTHREAD(CT1, clock.pos());
reset_si gnal _is(reset, true);
SC_CTHREAD(CT2, clock.pos());
async_reset_signal_is(async_reset, true);
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


46
Copyright 2012 IEEE. All rights reserved.
}
void CT1()
{
if (reset)
{
... // Reset acti ons
}
whil e(true)
{
wait(1); // Wait for 1 clock cycle
... // Clocked actions
}
}
void CT2()
{
... // Reset actions
whil e(true)
{
try {
whil e (true)
{
wait(); // Wai t f or 1 cl ock cycl e
... // Regul ar behavior
}
}
catch (...) // Some excepti on has been thrown
{
... // Handl e exception and go back to waiting for cl ock
}
}
}
5.2.13 reset_signal_is and async_reset_signal_is
void reset_signal_is( const sc_in<bool >& , bool );
void reset_signal_is( const sc_inout<bool>& , bool );
void reset_signal_is( const sc_out<bool >& , bool );
void reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
void async_reset_signal_is( const sc_in<bool >& , bool );
void async_reset_signal_is( const sc_inout<bool >& , bool );
void async_reset_signal_is( const sc_out<bool >& , bool );
void async_reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
Member f uncti ons reset_signal_is and async_reset_signal_is of class sc_module shall determine the
synchronous and asynchronous reset si gnals, respectively, of a thread, cl ocked thread, or method process.
These two member f unctions shall only be cal led i n the body of the constructor, i n the
before_end_of_elaboration callback of a modul e, or in a member f uncti on call ed f rom the constructor or
cal lback, and only after havi ng created a process instance within that same constructor or call back.
The order of execution of the statements wi thin the body of the constructor or the
before_end_of_elaboration cal lback shall be used to associ ate the cal l to reset_signal_is or
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


47
Copyright 2012 IEEE. All rights reserved.
async_reset_signal_is with a particular process instance; the cal l i s associated with the most recentl y
created process instance. If a module is instanti ated wi thin the constructor or call back between the process
bei ng created and f uncti on reset_signal_is or async_reset_signal_is bei ng cal led, the ef f ect of cal li ng
reset_signal_isor async_reset_signal_isshall be undef ined.
The f irst argument passed to f uncti on reset_signal_is or async_reset_signal_is shall identif y the signal
instance to be used as the reset. The si gnal may be identi fi ed indirectly by passi ng a port instance that i s
bound to the reset si gnal . The second argument shall be the active l evel of the reset si gnal, meaning that the
process is to be reset only when the val ue of the reset signal is equal to the val ue of this second argument.
When the reset signal (as specif ied by the fi rst argument) attains its active value (as specif ied by the second
argument), the process instance shall enter the synchr onous reset state. Whil e i n the synchronous reset state,
a process i nstance shal l be reset each ti me it is resumed, whether due to an event notif i cati on or to a time-
out. Bei ng reset in thi s sense shall have the same ef fect as would a cal l to the reset method of a process
handl e associ ated wi th the gi ven process instance. The synchronous reset state is descri bed more ful l y i n
5.6.6.3.
I f a process instance enters the synchronous reset state whil e it i s suspended (meaning that suspendhas been
cal led), the behavior shal l be impl ementation-defi ned (see 5.6.6.11).
I n the case of async_reset_signal_isonl y, the process shall also be reset whenever the reset si gnal attains i ts
active value. Being reset in thi s sense shall have the same ef fect as woul d a cal l to the reset method of a
process handle associ ated with the given process instance. Since the reset signal is itsel f a pri mitive channel
that can only change value i n the update phase, the process instance shall be reset by ef f ecti vel y cal li ng the
reset method of an associated process handle at some ti me duri ng the eval uation phase immediately
f ol lowi ng the reset si gnal attaining its active val ue and in an order determined by the kernel. An
asynchronous reset does not take priori ty over other processes that are due to run i n the same eval uation
phase.
When an asynchronous reset signal attai ns its acti ve value, the consequent reset shal l have the same priori ty
as a call to reset. When a process i nstance is reset whil e in the synchronous reset state, the consequent reset
shall have the same priori ty as sync_reset_on, regardless of whether the reset signal is synchronous or
asynchronous (see 5.6.6.11).
A gi ven process i nstance may have any number of synchronous and asynchronous reset signal s. When al l
such reset signals attain the negati on of their acti ve value, the process instance shal l leave the synchronous
reset state unl ess a call to sync_reset_on is in f orce f or the given process instance (see 5.6.6.3).
reset_signal_is and async_reset_signal_is are permi tted for method processes. The eff ect of resetti ng a
method process shall be to cancel any dynami c sensi ti vity, to restore the stati c sensitivi ty, and to cal l the
f uncti on associ ated with that process instance.
Exampl e:
SC_METHOD(rtl _proc);
sensitive << cl ock.pos();
async_reset_signal _i s(reset, true);
...
void rtl_proc()
{
if (reset)
// Asynchronous reset behavi or, executed whenever the reset i s acti ve
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


48
Copyright 2012 IEEE. All rights reserved.
else
// Synchronous behavior, only executed on a posi ti ve clock edge
}
5.2.14 sensitive
sc_sensi ti ve

sensitive;
This subcl ause descri bes the static sensi ti vity of an unspawned process. Static sensi ti vi ty for a spawned
process is created usi ng member function set_sensitivity of class sc_spawn_options(see 5.5).
Data member sensitive of class sc_module can be used to create the stati c sensiti vity of an unspawned
process i nstance usi ng operator<< of cl ass sc_sensi ti ve

(see 5.4). This shall be the onl y way to create static


sensiti vity f or an unspawned process instance. However, static sensi ti vity may be enabl ed or di sabled by
cal li ng f uncti on next_trigger (see 5.2.17) or functi on wait (see 5.2.18).
Static sensitivity shal l onl y be created i n the body of the constructor, in the before_end_of_elaboration or
end_of_elaboration call backs of a module, or in a member function cal led f rom the constructor or cal lback,
and only after having created an unspawned process instance wi thin that same constructor or call back. I t
shall be an error to modi fy the stati c sensitivi ty of an unspawned process duri ng simul ation.
The order of execution of the statements wi thin the body of the constructor or the
before_end_of_elaboration or end_of_elaboration cal lbacks i s used to associate stati c sensi ti vity with a
parti cul ar unspawned process i nstance; sensitivity is associ ated with the process i nstance most recently
created wi thi n the body of the current constructor or call back.
A clocked thread process cannot have stati c sensitivity other than to the clock i tself . Usi ng data member
sensitiveto create static sensitivity for a clocked thread process shal l have no ef fect.
NOTE 1Unrelated statements may be executed between creating an unspawned process i nstance and creati ng the
stati c sensi ti vi ty f or that same process i nstance. Stati c sensiti vi ty may be created i n a di ff erent f uncti on body f rom the
one i n whi ch the process i nstance was created.
NOTE 2Data member sensitive can be used more than once to add to the stati c sensi ti vi ty of any parti cul ar
unspawned process i nstance; each cal l to operator<< adds f urther events to the stati c sensi ti vi ty of the most recentl y
created process i nstance.
5.2.15 dont_initialize
void dont_initialize();
This subcl ause describes member f unction dont_initialize of class sc_module, which determines the
behavior of an unspawned process instance during initiali zation. The i niti ali zati on behavior of a spawned
process is determined by the member functi on dont_initializeof class sc_spawn_options(see 5.5).
Member f unction dont_initializeof cl ass sc_moduleshal l prevent a particular unspawned process i nstance
f rom bei ng made runnable duri ng the ini tial ization phase of the schedul er. In other words, the member
f uncti on associated with the gi ven process i nstance shall not be cal led by the schedul er until the process
instance is triggered or resumed because of the occurrence of an event.
dont_initialize shal l only be call ed in the body of the constructor, in the before_end_of_elaboration or
end_of_elaboration call backs of a module, or in a member function cal led f rom the constructor or cal lback,
and only after havi ng created an unspawned process instance wi thin that same constructor or cal lback.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


49
Copyright 2012 IEEE. All rights reserved.
The order of execution of the statements wi thin the body of the constructor or the
before_end_of_elaboration or end_of_elaboration cal lbacks is used to associate the cal l to
dont_initializewi th a parti cul ar unspawned process instance; it is associ ated wi th the most recentl y created
process i nstance. I f a module is i nstantiated within the constructor or call back between the process being
created and function dont_initializebei ng call ed, the eff ect of cal li ng dont_initializeshall be undef ined.
dont_initializeshall have no ef fect if called f or a clocked thread process, whi ch is not made runnabl e during
the ini ti al ization phase i n any case. An impl ementation may generate a warni ng but i s not obli ged to do so.
Exampl e:
SC_MODULE(Mod)
{
sc_signal<bool > A, B, C, D, E;
SC_CTOR(Mod)
{
sensitive << A; // Has no eff ect. Poor codi ng styl e

SC_THREAD(T);
sensitive << B << C; // Thread process T is made sensitive to B and C.
SC_METHOD(M);
f (); // Method process M is made sensitive to D.
sensitive << E; // Method process M is made sensitive to E as well as D.
dont_initiali ze(); // Method process M is not made runnabl e during initiali zation.
}
void f() { sensi ti ve << D; } // An unusual coding styl e
void T();
void M();
...
} ;
5.2.16 set_stack_size
void set_stack_size( si ze_t );
This subcl ause describes member f uncti on set_stack_sizeof class sc_module, which sets the stack si ze of
an unspawned process instance duri ng ini ti al ization. The stack size of a spawned process i s set by the
member f uncti on set_stack_sizeof class sc_spawn_options(see 5.5).
An appli cation may call member f uncti on set_stack_size to request a change to the si ze of the executi on
stack for the thread or clocked thread process instance for which the functi on is call ed. The ef f ect of this
functi on i s i mplementati on-defi ned.
set_stack_size shal l only be called i n the body of the constructor, i n the before_end_of_elaboration or
end_of_elaboration call backs of a module, or in a member function cal led f rom the constructor or cal lback,
and only after having created an unspawned process instance wi thin that same constructor or call back. I t
shal l be an error to call set_stack_sizeat other times or to call set_stack_sizefor a method process i nstance.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


50
Copyright 2012 IEEE. All rights reserved.
The order of execution of the statements wi thin the body of the constructor or the
before_end_of_elaborationor end_of_elaboration cal lbacks i s used to associ ate the cal l to set_stack_size
wi th a particular unspawned process i nstance; i t i s associated wi th the most recentl y created unspawned
process instance.
5.2.17 next_trigger
This subclause shall apply to both spawned and unspawned process instances.
This subclause shall apply to member functi on next_trigger of class sc_module, member function
next_trigger of class sc_prim_channel, and non-member functi on next_trigger.
When cal led wi th one or more arguments, the f unction next_trigger shal l set the dynamic sensitivi ty of the
method process instance from which it is called f or the very next occasi on on whi ch that process instance is
triggered, and for that occasi on only. The dynamic sensitivity is determined by the arguments passed to
functi on next_trigger.
If functi on next_trigger is cal led more than once duri ng a si ngl e executi on of a parti cul ar method process
instance, the last call to be executed shal l prevail . The ef fects of earl ier call s to f uncti on next_trigger f or
that particular process instance shal l be cancell ed.
I f function next_trigger is not cal led during a parti cular executi on of a method process i nstance, the method
process instance shall next be tri ggered according to its static sensi ti vi ty.
A call to the function next_trigger wi th one or more arguments shal l override the stati c sensi ti vity of the
process instance.
I t shall be an error to call function next_trigger from a thread or cl ocked thread process.
NOTEThe function next_trigger does not suspend the method process i nstance; a method process cannot be
suspended but al ways executes to compl etion bef ore returni ng control to the kernel .
void next_trigger();
The process shall be tri ggered on the static sensitivi ty. In the absence of static sensi ti vity for this
parti cul ar process instance, the process shall not be tri ggered again during the current simul ation.
Call ing next_trigger wi th an empty argument li st shal l cancel the eff ect of any earlier cal ls to
next_trigger duri ng the current execution of the method process i nstance and, thus, in eff ect shal l
be equivalent to not cal li ng next_trigger at all during a given process executi on.
void next_trigger( const sc_event& );
The process shal l be tri ggered when the event passed as an argument is notif ied.
void next_trigger( const sc_event_or_li st & );
The argument shal l take the form of a li st of events separated by the operator| of class sc_event or
sc_event_or_list. The process shall be triggered when any one of the given events i s noti fi ed. The
occurrence or non-occurrence of the other events in the l ist shall have no ef fect on that parti cul ar
triggeri ng of the process. I f a particular event appears more than once in the l ist, the behavior shal l
be the same as if that event had appeared only once. I t shall be an error to pass an empty event l ist
object as an argument to next_trigger (see 5.8 and 5.9).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


51
Copyright 2012 IEEE. All rights reserved.
void next_trigger( const sc_event_and_li st & );
The argument shall take the form of a l ist of events separated by the operator& of cl ass sc_event or
sc_event_and_list. I n order f or the process to be triggered, every si ngl e one of the gi ven events
shal l be noti fi ed, wi th no expli ci t constraints on the time or order of those notif icati ons. The process
is triggered when the last such event is noti fi ed, last in the sense of being at the l atest point i n
simul ation ti me, not last in the li st. An event i n the l ist may be noti fi ed more than once before the
last event is noti fi ed. I f a particul ar event appears more than once i n the l ist, the behavior shal l be the
same as if that event had appeared onl y once. It shall be an error to pass an empty event li st object as
an argument to next_trigger (see 5.8 and 5.9).
void next_trigger( const sc_ti me& );
The process shal l be triggered after the time gi ven as an argument has elapsed. The time shall be
taken to be relati ve to the ti me at whi ch f uncti on next_trigger is call ed. When a process is tri ggered
in thi s way, a ti me-out is said to have occurred. I n this method cal l and i n those that f oll ow below,
the argument that specif ies the time-out shall not be negati ve.
void next_trigger( double v , sc_time_uni t tu );
is equi val ent to the f oll owing:
void next_tri gger( sc_ti me( v , tu ) );
void next_trigger( const sc_ti me& , const sc_event& );
The process shall be triggered after the gi ven time or when the given event is notif ied, whi chever
occurs f irst.
void next_trigger( double , sc_ti me_unit , const sc_event& );
void next_trigger( const sc_ti me& , const sc_event_or_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_or_li st & );
void next_trigger( const sc_ti me& , const sc_event_and_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_and_li st & );
Each of these compound f orms combi nes a time with an event or event l ist. The semantics of these
compound forms shal l be deduced from the rul es given f or the simpl e f orms. In each case, the
process shall be triggered after the given time-out or in response to the given event or event l ist,
whichever is sati sf ied fi rst.
Exampl e:
SC_MODULE(M)
{
SC_CTOR(M)
{
SC_METHOD(entry);
sensitive << si g;
}
void entry() // Run first at ini ti al ization.
{
if (sig == 0) next_tri gger(e1 | e2); // Trigger on event e1 or event e2 next ti me
else i f (si g == 1) next_tri gger(1, SC_NS); // Ti me-out after 1 nanosecond.
else next_tri gger(); // Tri gger on si gnal sig next ti me.
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


52
Copyright 2012 IEEE. All rights reserved.
sc_signal <int> si g;
sc_event e1, e2;
...
} ;
5.2.18 wait
This subclause shall apply to both spawned and unspawned process instances.
I n addition to causing the process instance to suspend, the functi on wait may set the dynami c sensitivity of
the thread or clocked thread process instance from whi ch it i s cal led f or the very next occasion on whi ch that
process i nstance is resumed, and for that occasion only. The dynami c sensitivity i s determi ned by the
arguments passed to function wait.
A call to the function wait wi th an empty argument list or with a si ngl e i nteger argument shall use the static
sensitivity of the process i nstance. This is the onl y f orm of wait permi tted wi thin a cl ocked thread process.
A cal l to the f uncti on wait with one or more non-integer arguments shal l overri de the static sensi tivi ty of the
process instance.
When cal ling functi on wait wi th a passed-by-reference parameter, the appli cation shall be obli ged to ensure
that the li feti mes of any actual arguments passed by reference extend f rom the ti me the functi on i s call ed to
the time the functi on call reaches compl eti on, and moreover in the case of a parameter of type sc_time, the
appl icati on shal l not modif y the value of the actual argument duri ng that peri od.
I t shall be an error to call function wait from a method process.
void wait();
The process shall be resumed on the stati c sensitivi ty. In the absence of stati c sensitivi ty for thi s
particul ar process, the process shal l not be resumed agai n during the current si mulati on.
void wait( i nt );
A cal l to this functi on shal l be equivalent to call ing the function wait wi th an empty argument l ist
f or a number of ti mes in i mmedi ate successi on, the number of times bei ng passed as the val ue of the
argument. I t shall be an error to pass an argument val ue less than or equal to zero. The
impl ementation i s expected to opti mize the executi on speed of thi s function f or clocked thread
processes.
void wait( const sc_event& );
The process shal l be resumed when the event passed as an argument i s noti fi ed.
void wait( const sc_event_or_l ist &);
The argument shal l take the form of a l ist of events separated by the operator| of cl asses sc_event
and sc_event_or_list. The process shal l be resumed when any one of the gi ven events is notif ied.
The occurrence or non-occurrence of the other events in the l ist shall have no eff ect on the
resumpti on of that particular process. I f a parti cul ar event appears more than once in the li st, the
behavior shal l be the same as i f i t appeared onl y once. It shall be an error to pass an empty event l ist
object as an argument to wait (see 5.8 and 5.9).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


53
Copyright 2012 IEEE. All rights reserved.
void wait( const sc_event_and_li st & );
The argument shall take the f orm of a li st of events separated by the operator& of classes sc_event
and sc_event_and_list. I n order f or the process to be resumed, every si ngl e one of the given events
shal l be noti fi ed, wi th no expli ci t constraints on the time or order of those notif icati ons. The process
is resumed when the l ast such event i s noti fi ed, l ast i n the sense of bei ng at the l atest poi nt in
simul ation ti me, not last in the li st. An event i n the l ist may be noti fi ed more than once before the
last event is noti fi ed. I f a particul ar event appears more than once i n the l ist, the behavior shal l be the
same as i f it appeared only once. I t shall be an error to pass an empty event l ist obj ect as an argument
to wait (see 5.8 and 5.9).
void wait( const sc_ti me& );
The process shall be resumed after the ti me given as an argument has el apsed. The time shall be
taken to be relati ve to the ti me at whi ch functi on wait is call ed. When a process is resumed in this
way, a ti me-out i s said to have occurred. In this method cal l and in those that f ol low below, the
argument that speci fi es the time-out shall not be negati ve.
void wait( double v , sc_time_unit tu );
is equi val ent to the f oll owing:
void wait( sc_ti me( v, tu ) );
void wait( const sc_ti me& , const sc_event& );
The process shal l be resumed after the given time or when the given event i s notif ied, whi chever
occurs f irst.
void wait( double , sc_time_unit , const sc_event& );
void wait( const sc_ti me& , const sc_event_or_l ist & );
void wait( double , sc_time_unit , const sc_event_or_l ist & );
void wait( const sc_ti me& , const sc_event_and_l ist & );
void wait( double , sc_time_unit , const sc_event_and_l ist & );
Each of these compound f orms combi nes a time with an event or event l ist. The semantics of these
compound forms shal l be deduced from the rul es given f or the simpl e f orms. In each case, the
process shall be resumed after the given ti me-out or i n response to the gi ven event or event li st,
whichever is sati sf ied fi rst.
5.2.19 Positional port binding
Ports can be bound usi ng ei ther positional binding or named bi ndi ng. Positional bi nding is perf ormed usi ng
the operator() def ined in the current subcl ause. Named binding is perf ormed using the operator() or the
functi on bind of the class sc_port (see 5.12).
void operator() (
const sc_bi nd_proxy

& p001,
const sc_bi nd_proxy

& p002 = SC_BIND_PROXY_NIL,


...
const sc_bi nd_proxy

& p063 = SC_BIND_PROXY_NIL,


const sc_bi nd_proxy

& p064 = SC_BIND_PROXY_NIL );


This operator shal l bi nd the port instances within the module instance f or whi ch the operator i s call ed to the
channel instances and port instances passed as actual arguments to the operator, the port order being
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


54
Copyright 2012 IEEE. All rights reserved.
determi ned by the order i n which the ports were constructed. The f irst port to be constructed shall be bound
to the f irst argument, the second port to the second argument, and so f orth. I t shal l be an error i f the number
of actual arguments i s greater than the number of ports to be bound.
A mul ti port i nstance (see 5.12.3) shall be treated as a single port i nstance when posi ti onal binding is used
and may only be bound once, to a si ngl e channel instance or port instance. However, if a multiport instance
P is bound by position to another mul ti port instance Q, the chil d mul ti port P may be bound indirectl y to
more than one channel through the parent mul tiport Q. A gi ven multiport shal l not be bound both by position
and by name.
This operator shall only bind ports, not exports. Any export i nstances contained within the modul e instance
shall be i gnored by this operator.
An i mplementation may permi t more than 64 ports to be bound i n a si ngl e call to operator() by all owing
more than 64 arguments but i s not obl iged to do so. operator() shal l not be cal led more than once f or a given
module instance.
The f oll owi ng obj ects, and these alone, can be used as actual arguments to operator():
a) A channel, which is an object of a class derived f rom cl ass sc_interface
b) A port, whi ch i s an obj ect of a cl ass derived f rom cl ass sc_port
The type of a por t i s the name of the interface passed as a templ ate argument to class sc_port when the port
is instanti ated. The i nterf ace impl emented by the channel in case a) or the type of the port i n case b) shall be
the same as or deri ved from the type of the port bei ng bound.
An implementation may def er the completi on of port binding until a later time duri ng el aboration because
the port to whi ch a port i s bound may not yet i tself have been bound. Such def erred port binding shal l be
completed by the impl ementation bef ore the call backs to f unction end_of_elaboration.
NOTE 1To bind more than 64 ports of a single modul e instance, named bi ndi ng should be used.
NOTE 2Class sc_bi nd_proxy

, the parameter type of operator(), may provi de user-def i ned conversi ons i n the form of
two constructors, one havi ng a parameter type of sc_interface, and the other a parameter type of sc_port_base.
NOTE 3The actual argument cannot be an export, because thi s woul d requi re the C++ compi l er to perf orm two
i mpl i ci t conversi ons. However, i t i s possibl e to pass an export as an actual argument by expl i ci tl y cal l i ng the user-
defi ned conversi on sc_export::operator I F&. I t i s al so possi bl e to bi nd a port to an export usi ng named port bi ndi ng.
Exampl e:
SC_MODULE(M1)
{
sc_inout<i nt> P, Q, R; // Ports
...
} ;
SC_MODULE(Top1)
{
sc_i nout <i nt> A, B;
sc_signal <int> C;
M1 m1; // Module instance
SC_CTOR(Top1)
: m1("m1")
{
m1(A, B, C); // Binds P-to-A, Q-to-B, R-to-C
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


55
Copyright 2012 IEEE. All rights reserved.
}
...
} ;
SC_MODULE(M2)
{
sc_inout<i nt> S;
sc_i nout<i nt> * T; // Pointer-to-port (an unusual coding styl e)
sc_i nout<i nt> U;
SC_CTOR(M2) { T = new sc_inout<i nt>; }
...
} ;
SC_MODULE(Top2)
{
sc_i nout <i nt> D, E;
sc_signal <int> F;
M2 m2; // Module instance
SC_CTOR(Top2)
: m2("m2")
{
m2(D, E, F); // Bi nds S-to-D, U-to-E, (* T)-to-F
// Note that binding order depends on the order of port construction
}
...
} ;
5.2.20 before_end_of_elaboration, end_of_elaboration, start_of_simulation,
end_of_simulation
See 4.4.
5.2.21 get_child_objects and get_child_events
virtual const std::vector<sc_object* >& get_child_objects() const;
Member f uncti on get_child_objectsshall return a std::vector containi ng a pointer to every i nstance
of class sc_object that li es wi thi n the modul e in the object hi erarchy. This shall i nclude pointers to
all modul e, port, pri mi ti ve channel , unspawned process, and spawned process i nstances wi thi n the
module and any other appl icati on-def ined obj ects deri ved from cl ass sc_object wi thin the modul e.
virtual const std::vector<sc_event* >& get_child_events() const;
Member functi on get_child_eventsshall return a std::vector contai ni ng a poi nter to every object of
type sc_event that i s a hierarchicall y named event and whose parent is the current module.
NOTE 1The phrase wi thi n a modul edoes not i ncl ude i nstances nested wi thi n modules i nstances but only i ncl udes the
i mmedi ate chi l dren of the gi ven modul e.
NOTE 2An application can identi f y the i nstances by cal l i ng the member f uncti ons nameand kind of cl ass sc_object
or can determi ne thei r types usi ng a dynami c cast.
NOTE 3An event may have a hierarchical name and may have a parent i n the obj ect hi erarchy, but in any case events
are not themsel ves part of the obj ect hi erarchy.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


56
Copyright 2012 IEEE. All rights reserved.
Exampl e:
int sc_main (i nt argc, char* argv[] )
{
Top_l evel_module top("top");
std::vector<sc_obj ect* > chil dren = top.get_chil d_objects();
// Pri nt out names and kinds of top-level objects
f or (unsigned i = 0; i < chi ldren.si ze(); i++)
std::cout << chil dren[i ]->name() << " " << chi ldren[ i] ->kind() << std::endl;
sc_start();
return 0;
}
5.2.22 sc_gen_unique_name
const char* sc_gen_unique_name( const char* seed );
The functi on sc_gen_unique_name shall return a uni que character string that depends on the context from
which the f uncti on i s call ed. For this purpose, each module instance shal l have a separate space of uni que
string names, and there shall be a single global space of unique stri ng names for cal ls to
sc_gen_unique_name not made from within any module. These spaces of unique stri ng names shal l be
maintai ned by f uncti on sc_gen_unique_name and are onl y vi si bl e outside thi s functi on i n so f ar as they
aff ect the value of the stri ngs returned f rom this f uncti on. Functi on sc_gen_unique_name shal l onl y
guarantee the uniqueness of strings withi n each space of unique string names. There shal l be no guarantee
that the generated name does not cl ash with a string that was not generated by f unction
sc_gen_unique_name.
The unique string shall be constructed by appending a stri ng of two or more characters as a suf fi x to the
character stri ng passed as argument seed, subject to the rules given i n the remainder of this subcl ause. The
appended suff ix shall take the f orm of a single underscore character, foll owed by a series of one of more
deci mal digits f rom the character set 0-9. The number and choice of digits shal l be impl ementation-defi ned.
There shall be no restrictions on the character set of the seed argument to function sc_gen_unique_name.
The seed argument may be the empty stri ng.
String names are case-sensitive, and every character in a string name is si gni fi cant. For example, a, A,
a_, and A_ are each unique string names with respect to one another.
NOTEThe intended use of sc_gen_unique_nameis to generate uni que stri ng names f or obj ects of cl ass sc_object.
Cl ass sc_object does impose restri ctions on the character set of stri ng names passed as constructor arguments. The value
returned f rom f uncti on sc_gen_unique_namemay be used f or other unrel ated purposes.
5.2.23 sc_behavior and sc_channel
typedef sc_modul e sc_behavior;
typedef sc_modul e sc_channel;
The typedefs sc_behavior and sc_channel are provided f or users to express their intent.
NOTEThere is no distinction between a behavi or and a hi erarchi cal channel other than a dif f erence of i ntent. Ei ther
may i ncl ude both ports and publ i c member functi ons.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


57
Copyright 2012 IEEE. All rights reserved.
Exampl e:
class bus_interface
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual void wri te(i nt addr, int data) = 0;
virtual void read (int addr, i nt& data) = 0;
} ;
class bus_adapter
: publi c bus_i nterf ace, publi c sc_channel
{
publ ic:
virtual void wri te(i nt addr, int data); // Interface methods impl emented in channel
virtual void read (int addr, int& data);
sc_i n<bool> clock; // Ports
sc_out<bool> wr, rd;
sc_out<i nt> addr_bus;
sc_out<i nt> data_out;
sc_in <i nt> data_i n;
SC_CTOR(bus_adapter) { ... } // Module constructor
pri vate:
...
} ;
5.3 sc_module_name
5.3.1 Description
Cl ass sc_module_nameacts as a contai ner for the string name of a modul e and provi des the mechanism f or
buil di ng the hierarchi cal names of instances in the modul e hi erarchy duri ng elaborati on.
When an appli cation creates an object of a class derived di rectly or indi rectly from cl ass sc_module, the
appl icati on typicall y passes an argument of type char* to the module constructor, whi ch itsel f has a single
parameter of class sc_module_nameand thus the constructor sc_module_name( const char* ) i s call ed as
an i mpli ci t conversi on. On the other hand, when an applicati on deri ves a new cl ass di rectl y or i ndi rectl y
f rom class sc_module, the derived cl ass constructor call s the base class constructor wi th an argument of
class sc_module_name and thus the copy constructor sc_module_name( const sc_module_name& ) i s
cal led.
5.3.2 Class definition
namespace sc_core {
class sc_module_name
{
publ ic:
sc_module_name( const char* );
sc_module_name( const sc_modul e_name& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


58
Copyright 2012 IEEE. All rights reserved.
~sc_module_name();
operator const char*() const;
pri vate:
// Di sabl ed
sc_module_name();
sc_module_name& operator= ( const sc_modul e_name& );
} ;
} // namespace sc_core
5.3.3 Constraints on usage
Cl asssc_module_nameshall onl y be used as the type of a parameter of a constructor of a class derived from
class sc_module. Moreover, every such constructor shal l have exactl y one parameter of type
sc_module_name, which need not be the fi rst parameter of the constructor.
I n the case that the constructor of a class C derived di rectly or i ndi rectly from cl ass sc_module is call ed
f rom the constructor of a class D deri ved di rectly from class C, the parameter of type sc_module_nameof
the constructor of class D shal l be passed di rectl y through as an argument to the constructor of cl ass C. I n
other words, the derived class constructor shall pass the sc_module_name through to the base cl ass
constructor as a constructor argument.
NOTE 1The macro SC_CTOR defines such a constructor.
NOTE 2In the case of a class C derived di rectl y f rom class sc_module, the constructor f or cl ass C i s not obl i ged to
pass the sc_module_namethrough to the constructor f or cl ass sc_module. The defaul t constructor f or cl ass sc_module
may be cal l ed expli ci tl y or i mpl ici tl y f rom the constructor f or cl ass C.
5.3.4 Module hierarchy
To keep track of the module hierarchy during elaborati on, the impl ementation may mai ntain an i nternal
stack of poi nters to obj ects of cl ass sc_module_name, referred to below as the stack. For the purpose of
buildi ng hierarchical names, when objects of class sc_module, sc_port, sc_export, sc_prim_channel, or
sc_event are constructed or when spawned or unspawned processes i nstances are created, they are assumed
to exist wi thin the module identif ied by the sc_module_nameobj ect on the top of the stack. In other words,
each i nstance in the modul e hierarchy is named as if it were a chi ld of the module i denti fi ed by the item on
the top of the stack at the poi nt when the instance is created.
The impl ementation is not obli ged to use these parti cul ar mechanisms (a stack of pointers), but if not, the
impl ementation shall substitute an al ternati ve mechanism that is semanti cal ly equi val ent.
NOTE 1The hi erar chi cal nameof an i nstance i n the obj ect hierarchy is returned f rom member f uncti on nameof cl ass
sc_object, whi ch i s the base cl ass of al l such i nstances.
NOTE 2An object of type sc_event may have a hi erarchi cal name and may have a parent i n the obj ect hi erarchy, but
i n any casesc_event i s not deri ved f rom sc_object and events are not themsel ves part of the obj ect hierarchy.
5.3.5 Member functions
sc_module_name( const char* );
This constructor shall push a poi nter to the obj ect being constructed onto the top of the stack. The
constructor argument shal l be used as the string name of the module being i nstantiated wi thin the
module hierarchy by ultimatel y being passed as an argument to the constructor of cl ass sc_object.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


59
Copyright 2012 IEEE. All rights reserved.
sc_module_name( const sc_modul e_name& );
This constructor shall copy the constructor argument but shal l not modif y the stack.
~sc_module_name();
I f and onl y if the object being destroyed was constructed by sc_module_name( const char* ), the
destructor shal l remove the sc_module_namepoi nter f rom the top of the stack.
operator const char*() const;
This conversi on f unction shall return the string name (not the hierarchi cal name) associated with the
sc_module_name.
NOTE 1When a compl ete obj ect of a cl ass deri ved f rom sc_modulei s constructed, the constructor f or that
deri ved cl ass i s passed an argument of type char*. The f i rst constructor above wi l l be cal l ed to perf orm an
i mpl i ci t conversi on f rom type char* to type sc_module_name, thus pushi ng the newl y created modul e name
onto the stack and si gni f yi ng the entry i nto a new l evel i n the modul e hierarchy. On return f rom the constructor
f or the cl ass of the compl ete obj ect, the destructor f or cl ass sc_module_namewi l l be cal l ed and wi l l remove
the modul e name f rom the stack.
NOTE 2When an sc_module_name i s passed as an argument to the constructor of a base class, the above
copy constructor i s cal l ed. The sc_module_name parameter of the base cl ass may be unused. The reason for
mandati ng that every such constructor have a parameter of cl ass sc_module_name (even i f the parameter i s
unused) i s to ensure that every such deri ved cl ass can be i nstanti ated as a modul e in i ts own ri ght.
Exampl e:
struct A: sc_module
{
A(sc_modul e_name) { } // Cal ls sc_module()
} ;
struct B: sc_modul e
{
B(sc_modul e_name n)
: sc_modul e(n) { } // Cal ls sc_modul e(sc_module_name&)
} ;
struct C: B // One module derived from another
{
C(sc_modul e_name n)
: B(n) { } // Cal ls sc_module_name(sc_modul e_name&) then
// B(sc_modul e_name)
} ;
struct Top: sc_modul e
{
A a;
C c;
Top(sc_module_name n)
: sc_modul e(n), // Cal ls sc_modul e(sc_module_name&)
a("a"), // Cal ls sc_module_name(char* ) then cal ls A(sc_modul e_name)
c("c") { } // Calls sc_module_name(char* ) then cal ls C(sc_modul e_name)
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


60
Copyright 2012 IEEE. All rights reserved.
5.4 sc_sensitive

5.4.1 Description
Cl ass sc_sensi ti ve

provides the operators used to bui ld the stati c sensitivi ty of an unspawned process
instance. To create stati c sensi ti vity f or a spawned process, use the member function set_sensitivity of the
class sc_spawn_options(see 5.5).
5.4.2 Class definition
namespace sc_core {
class sc_sensi ti ve

{
publ ic:
sc_sensi ti ve

& operator<< ( const sc_event& );


sc_sensi ti ve

& operator<< ( const sc_interface& );


sc_sensi ti ve

& operator<< ( const sc_port_base& );


sc_sensi ti ve

& operator<< ( sc_event_fi nder& );


// Other members
i mpl ementati on-defi ned
} ;
} // namespace sc_core
5.4.3 Constraints on usage
An appl ication shall not expli ci tl y create an obj ect of cl ass sc_sensi ti ve

.
Cl ass sc_module shal l have a data member named sensitive of type sc_sensi ti ve

. The use of sensitive to


create static sensitivity i s described i n 5.2.14.
5.4.4 operator<<
sc_sensi ti ve

& operator<< ( const sc_event& );


The event passed as an argument shal l be added to the static sensitivity of the process i nstance.
sc_sensi ti ve

& operator<< ( const sc_interface& );


The event returned by member functi on default_event of the channel instance passed as an
argument to operator<< shal l be added to the stati c sensitivi ty of the process instance.
NOTE 1If the channel passed as an argument does not overri de f uncti on default_event, the member f uncti on
default_event of cl ass sc_interfacei s cal l ed through i nheri tance.
NOTE 2An export can be passed as an actual argument to thi s operator because of the exi stence of the user-
defi ned conversi on sc_export<I F>::operator.
sc_sensi ti ve

& operator<< ( const sc_port_base& );


The event returned by member function default_event of the channel instance to whi ch the port
instance passed as an argument to operator<< is bound shall be added to the stati c sensi ti vi ty of the
process i nstance. I n other words, the process i s made sensi ti ve to the given port, call ing function
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


61
Copyright 2012 IEEE. All rights reserved.
default_event to determine to whi ch parti cul ar event i t shoul d be made sensiti ve. If the port i nstance
is a multiport (see 5.12.3), the events returned by cal li ng member f unction default_event f or each
and every channel instance to whi ch the mul ti port is bound shal l be added to the static sensitivity of
the process instance.
sc_sensi ti ve

& operator<< ( sc_event_fi nder& );


The event found by the event fi nder passed as an argument to operator<< shal l be added to the
stati c sensitivi ty of the process instance (see 5.7).
NOTEAn event finder is necessary to create static sensitivity when the application needs to select between
multi pl e events def i ned i n the channel . In a such a case, the default_event mechani sm i s i nadequate.
5.5 sc_spawn_options and sc_spawn
5.5.1 Description
Function sc_spawn is used to create a stati c or dynamic spawned process instance.
Cl ass sc_spawn_optionsi s used to create an object that is passed as an argument to function sc_spawn
when creati ng a spawned process instance. The spawn opti ons determine certai n properties of the spawned
process instance when used i n this way. Cal li ng the member functions of an sc_spawn_optionsobject shal l
have no ef fect on any process i nstance unless the object is passed as an argument to sc_spawn.
5.5.2 Class definition
namespace sc_core {
class sc_spawn_options
{
publ ic:
sc_spawn_options();
void spawn_method();
void dont_initialize();
void set_stack_size( i nt );
void set_sensitivity( const sc_event* );
void set_sensitivity( sc_port_base* );
void set_sensitivity( sc_export_base* );
void set_sensitivity( sc_interf ace* );
void set_sensitivity( sc_event_fi nder* );
void reset_signal_is( const sc_in<bool >& , bool );
void reset_signal_is( const sc_inout<bool >& , bool );
void reset_signal_is( const sc_out<bool >& , bool );
void reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
void async_reset_signal_is( const sc_in<bool >& , bool );
void async_reset_signal_is( const sc_inout<bool >& , bool );
void async_reset_signal_is( const sc_out<bool >& , bool );
void async_reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


62
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_spawn_options( const sc_spawn_options& );
sc_spawn_options& operator= ( const sc_spawn_options& );
} ;
templ ate <typename T>
sc_process_handle sc_spawn(
T obj ect ,
const char* name_p = 0 ,
const sc_spawn_opti ons* opt_p = 0 );
templ ate <typename T>
sc_process_handle sc_spawn(
typename T::resul t_type* r_p ,
T obj ect ,
const char* name_p = 0 ,
const sc_spawn_opti ons* opt_p = 0 );
#def ine sc_bind boost::bi nd
#def ine sc_ref(r) boost::ref (r)
#def ine sc_cref(r) boost::cref (r)
#def ine SC_FORK i mpl ementati on-defi ned
#def ine SC_JOI N i mpl ementati on-defi ned
} // namespace sc_core
namespace sc_unnamed {
i mpl ementati on-defi ned _1;
i mpl ementati on-defi ned _2;
i mpl ementati on-defi ned _3;
i mpl ementati on-defi ned _4;
i mpl ementati on-defi ned _5;
i mpl ementati on-defi ned _6;
i mpl ementati on-defi ned _7;
i mpl ementati on-defi ned _8;
i mpl ementati on-defi ned _9;
} // namespace sc_unnamed
5.5.3 Constraints on usage
Function sc_spawn may be call ed during elaborati on or from a static, dynami c, spawned, or unspawned
process during si mulati on. Simi larl y, obj ects of class sc_spawn_optionsmay be created or modif ied during
elaborati on or simul ation.
5.5.4 Constructors
sc_spawn_options();
The default constructor shall create an obj ect havi ng the def aul t val ues f or the properties set by the f unctions
spawn_method, dont_initialize, set_stack_size, and set_sensitivity.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


63
Copyright 2012 IEEE. All rights reserved.
5.5.5 Member functions
void spawn_method();
Member f unction spawn_method shal l set a property of the spawn opti ons to i ndi cate that the
spawned process shal l be a method process. The default is a thread process.
void dont_initialize();
Member f uncti on dont_initialize shall set a property of the spawn opti ons to i ndi cate that the
spawned process instance shal l not be made runnabl e during the i niti ali zati on phase or when i t is
created. By default, this property i s not set, and thus by default the spawned process i nstance shall be
made runnabl e during the ini ti al izati on phase of the schedul er i f spawned duri ng el aboration, or i t
shal l be made runnable i n the current or next eval uation phase if spawned duri ng simul ation
irrespecti ve of the static sensi ti vi ty of the spawned process instance. I f the process i s spawned
duri ng el aboration, member functi on dont_initialize of cl ass sc_spawn_optionsshall provide the
same behavi or for spawned processes as the member functi on dont_initialize of class sc_module
provides for unspawned processes.
void set_stack_size( i nt );
Member f uncti on set_stack_sizeshall set a property of the spawn options to set the stack size of the
spawned process. Thi s member f uncti on shal l provi de the same behavior f or spawned processes as
the member f uncti on set_stack_size of cl ass sc_module provi des f or unspawned processes. The
eff ect of cal li ng this functi on i s i mplementati on-def ined.
I t shall be an error to call set_stack_sizefor a method process.
void set_sensitivity( const sc_event* );
void set_sensitivity( sc_port_base* );
void set_sensitivity( sc_export_base* );
void set_sensitivity( sc_interf ace* );
void set_sensitivity( sc_event_fi nder* );
Member f uncti on set_sensitivity shall set a property of the spawn opti ons to add the object passed
as an argument to set_sensitivity to the static sensitivity of the spawned process, as described f or
operator<< i n 5.4.4, or if the argument is the address of an export, the process is made sensi ti ve to
the channel i nstance to which that export i s bound. I f the argument i s the address of a multiport, the
process shal l be made sensi ti ve to the events returned by call ing member f unction default_event for
each and every channel instance to whi ch the mul ti port is bound. By def aul t, the stati c sensitivity is
empty. Call s to set_sensitivity are cumulati ve: each call to set_sensitivity extends the stati c
sensitivity as set i n the spawn options. Call s to the f our di ff erent overl oaded member f uncti ons can
be mixed.
void reset_signal_is( const sc_in<bool >& , bool );
void reset_signal_is( const sc_inout<bool>& , bool );
void reset_signal_is( const sc_out<bool>& , bool );
void reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
void async_reset_signal_is( const sc_in<bool >& , bool );
void async_reset_signal_is( const sc_inout<bool >& , bool );
void async_reset_signal_is( const sc_out<bool >& , bool );
void async_reset_signal_is( const sc_si gnal _i n_i f<bool>& , bool );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


64
Copyright 2012 IEEE. All rights reserved.
Member functions reset_signal_is and async_reset_signal_is shal l set a property of the spawn
opti ons to add the obj ect passed as an argument as a synchronous or an asynchronous reset si gnal of
the spawned process instance, respecti vely, as described i n 5.2.13. Each call to ei ther of these
member functions shall add a reset si gnal to the gi ven spawn options obj ect. The signal may be
identi fi ed indirectly by passing a port instance that is bound to the reset signal . A spawned process
instance may have any number of synchronous and asynchronous reset signal s.
NOTE 1There are no member functions to set the spawn options to spawn a thread process or to make a process
runnabl e duri ng ini ti al i zati on. This f uncti onal i ty i s rel i ant on the def aul t val ues of the sc_spawn_optionsobj ect.
NOTE 2It is not possible to spawn a dynami c cl ocked thread process.
5.5.6 sc_spawn
templ ate <typename T>
sc_process_handle sc_spawn(
T obj ect ,
const char* name_p = 0 ,
const sc_spawn_opti ons* opt_p = 0 );
templ ate <typename T>
sc_process_handle sc_spawn(
typename T::resul t_type* r_p ,
T obj ect ,
const char* name_p = 0 ,
const sc_spawn_opti ons* opt_p = 0 );
#def ine sc_bind boost::bi nd
#def ine sc_ref(r) boost::ref (r)
#def ine sc_cref(r) boost::cref (r)
Function sc_spawn shal l create a stati c or dynamic spawned process instance.
Function sc_spawn may be cal led during elaborati on, i n which case the spawned process is a chi l d of the
module instance within which functi on sc_spawn is cal led or i s a top-l evel obj ect i f f unction sc_spawn is
cal led from function sc_main.
Function sc_spawn may be cal led duri ng si mulation, in which case the spawned process is a chil d of the
process that cal led f unction sc_spawn. Functi on sc_spawn may be cal led f rom a method process, a thread
process, or a cl ocked thread process.
The process or module from whi ch sc_spawn is cal led i s the parent of the spawned process. Thus a set of
dynami c process i nstances may have a hi erarchical rel ati onship, simi lar to the modul e hi erarchy, whi ch wi ll
be refl ected in the hierarchical names of the process instances.
If function sc_spawn is call ed duri ng the evaluati on phase, the spawned process shall be made runnable i n
the current evaluati on phase (unl ess dont_initialize has been cal led f or this process instance). I f functi on
sc_spawn i s call ed during the update phase, the spawned process shall be made runnable i n the very next
eval uation phase (unl ess dont_initializehas been cal led f or thi s process instance).
The argument of typeT shall be either a function pointer or a functi on object, that i s, an obj ect of a cl ass that
overloads operator() as a member f uncti on and shall speci fy the functi on associated with the spawned
process instance, that is, the functi on to be spawned. This shal l be the only mandatory argument to f unction
sc_spawn.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


65
Copyright 2012 IEEE. All rights reserved.
I f present, the argument of type T::result_type* shal l pass a poi nter to a memory l ocati on that shal l receive
the value returned from the f uncti on associ ated with the process i nstance. I n thi s case, the argument of type
T shall be a f unction object of a cl ass that exposes a nested type named result_type. Furthermore,
operator() of the function object shall have the return type result_type. I t is the responsi bil ity of the
appl icati on to ensure that the memory location is stil l val id when the spawned f uncti on returns. For example,
the memory location could be a data member of an encl osi ng sc_modulebut should not be a stack vari able
that would have been deal located by the time the spawned f uncti on returns. See the example bel ow.
The macros sc_bind, sc_ref, and sc_cref are provi ded for convenience when usi ng the f ree Boost C++
li brari es to bind arguments to spawned functions. Passi ng arguments to spawned processes i s a powerful
mechanism that al lows processes to be parameteri zed when they are spawned and permi ts processes to
update variables over time through ref erence arguments. boost::bind provi des a conveni ent way to pass
value arguments, ref erence arguments, and const reference arguments to spawned functions, but i ts use is
not mandatory. See the examples below and the Boost documentati on avai lable on the Internet.
The onl y purpose of namespace sc_unnamed i s to al low the i mplementati on to provide a set of argument
placeholders for use with sc_bind. _1, _2, _3 ... shal l be provi ded by the impl ementation to give access to
the pl aceholders of the same names from the Boost l ibrari es. These pl acehol ders can be passed as arguments
to sc_bind in order to defer the binding of function arguments until the cal l to the function obj ect returned
f rom sc_bind. Agai n, see the Boost documentati on f or detai ls.
The argument of type const char* shall gi ve the stri ng name of the spawned process i nstance and shal l be
passed by the i mplementati on to the constructor f or the sc_object that f orms the base class sub-obj ect of the
spawned process i nstance. I f no such argument i s gi ven or i f the argument i s an empty string, the
impl ementation shal l create a string name f or the process instance by call ing f unction sc_gen_unique_name
wi th the seed stri ng "thread_p" in the case of a thread process or "method_p" in the case of a method
process.
The argument of type sc_spawn_options* shall set the spawn options for the spawned process instance. If
no such argument i s provided, the spawned process instance shall take the default values as def ined for the
member functions of classsc_spawn_options. The appli cation i s not obli ged to keep the sc_spawn_options
object val id after the return f rom f uncti on sc_spawn.
Function sc_spawnshal l return a vali d process handl e to the spawned process i nstance. A process instance
can be suspended, resumed, disabled, enabled, kil led, or reset using the member f unctions of cl ass
sc_process_handle.
I f a spawn options argument is given, a process stri ng name argument shal l also be given, al though that
string name argument may be an empty stri ng.
NOTEFunction sc_spawnprovi des asuperset of the functi onal i ty of the macros SC_THREAD and SC_METHOD. I n
addi ti on to the f unctional i ty provi ded by these macros, f uncti on sc_spawnprovi des the passi ng of arguments and return
val ues to and f rom processes spawned duri ng el aborati on or si mul ati on. The macros are retai ned f or compati bi l i ty wi th
earli er versi ons of SystemC.
Exampl e:
int f();
struct Functor
{
typedef int result_type;
result_type operator() ();
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


66
Copyright 2012 IEEE. All rights reserved.
Functor::resul t_typeFunctor::operator() () { returnf(); }
int h(int a, i nt& b, const int& c);
struct MyMod: sc_module
{
sc_signal <int> si g;
void g();
SC_CTOR(MyMod)
{
SC_THREAD(T);
}
int ret;
void T()
{
sc_spawn(&f); // Spawn afunction wi thout argumentsand di scard any return value.
// Spawn asi mil ar process and createaprocess handle.
sc_process_handlehandle= sc_spawn(&f);
Functor fr;
sc_spawn(&ret, fr); // Spawn afuncti onobject andcatch thereturn value.
sc_spawn_optionsopt;
opt.spawn_method();
opt.set_sensi ti vi ty(&si g);
opt.dont_initiali ze();
sc_spawn(f, "f1", &opt); // Spawn amethod processnamed "f1", sensi ti veto sig, not initiali zed.
// Spawn asi mil ar process named "f2" and catch thereturn value.
sc_spawn(&ret, fr, "f2", &opt);
// Spawn amember function usi ng Boost bi nd.
sc_spawn(sc_bind(&MyMod::g, thi s));
int A = 0, B, C;
// Spawn afunction usi ng Boost bind, passarguments
// and catch thereturn val ue.
sc_spawn(&ret, sc_bi nd(&h, A, sc_ref(B), sc_cref(C)));
}
} ;
5.5.7 SC_FORK and SC_JOIN
#defineSC_FORK i mpl ementati on-defi ned
#defineSC_JOIN i mpl ementati on-defi ned
The macros SC_FORK and SC_JOIN can onl y be used as a pai r to bracket a set of cal ls to functi on
sc_spawn from within a thread or clocked thread process. It i s an error to use the fork-joi n construct in a
method process. Each call to sc_spawn (encl osed between SC_FORK and SC_JOIN) shall result i n a
separate process i nstance being spawned when control enters the fork-j oin construct. The chil d processes
shall be spawned without del ay and may potenti al ly all become runnable i n the current eval uation phase
(dependi ng on their spawn options). Thespawned process instances shal l be thread processes. It is an error
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


67
Copyright 2012 IEEE. All rights reserved.
to spawn amethod process withi n a fork-join construct. Control l eaves thefork-j oin construct when all the
spawned processi nstances haveterminated.
The text between SC_FORK and SC_JOIN shall consist of a series of one or more cal ls to function
sc_spawn separated by commas. Thevaluereturnedfromthefunction call may bedi scardedor thefuncti on
cal l may betheonly expressi onontheright-hand-sideof an assi gnment toavariable, wherethevari ablewil l
beset totheprocess handlereturned fromsc_spawn.
Thecommaafter thefi nal cal l to sc_spawn andi mmediatel y beforeSC_JOIN shal l beoptional . Thereshal l
be no other characters other than white space separati ng SC_FORK, the functi on cal ls, or variable
assignments, thecommas, and SC_JOIN. If anappl icati on violatestheserules, theeffect shall beundefi ned.
Exampl e 1:
SC_FORK
sc_spawn( arguments ) ,
sc_spawn( arguments ) ,
sc_spawn( arguments )
SC_JOIN
Exampl e 2:
sc_process_handleh1, h2, h3;
SC_FORK
h1 = sc_spawn( ar guments ) ,
h2 = sc_spawn( ar guments ) ,
h3 = sc_spawn( ar guments )
SC_JOIN
5.6 sc_process_handle
5.6.1 Description
Cl ass sc_process_handl e provi des a process handl e to an underlyi ng spawned or unspawned process
instance. A process handl e can be i n one of two states: val i d or i nval i d. A val i d process handle shal l be
associ ated with a si ngl e underl yi ng processi nstance, whi ch may or may not bei n thetermi nated state. An
i nval i d process handle may be associated wi th a single underlyi ng process i nstance provided that process
instance has termi nated. An empty process handle is an i nvali d handl e that is not associ ated wi th any
underlying process instance. In other words, an i nvali d process handl e is either an empty handl e or is
associ ated withaterminated processi nstance. A processi nstancemay beassoci ated withzero, oneor many
process handles, andthenumber and i denti ty of such processhandl esmay changeover ti me.
Since dynamic process i nstances can be created and destroyed dynamicall y duri ng simul ation, it is i n
general unsafeto manipulateaprocessinstancethrough araw pointer to theprocessinstance(or to thebase
class sub-object of class sc_obj ect). The purpose of class sc_process_handle i s to provide a safe and
uniform mechani sm for manipulating both spawned and unspawned process i nstances without reli ance on
raw pointers. If control returns from the functi on associated with a thread process instance (that is, the
process terminates), theunderl yi ng processi nstancemay bedel eted, but theprocesshandlewil l conti nueto
exi st.
The provi si on of oper ator <, which suppl ies a stri ct weak orderi ng relation on the underlyi ng process
instances, al lows processhandlestobestoredi n astandardC++ container such as std::map.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


68
Copyright 2012 IEEE. All rights reserved.
5.6.2 Class definition
namespace sc_core {
enum sc_curr_proc_kind
{
SC_NO_PROC_ ,
SC_METHOD_PROC_ ,
SC_THREAD_PROC_ ,
SC_CTHREAD_PROC_
} ;
enum sc_descendant_inclusion_info
{
SC_NO_DESCENDANTS,
SC_INCLUDE_DESCENDANTS
} ;
class sc_unwind_exception: publi c std::exception
{
publ ic:
virtual const char* what() const throw();
virtual bool is_reset() const;
protected:
sc_unwind_exception();
sc_unwind_exception( const sc_unwi nd_excepti on& );
virtual ~sc_unwind_exception() throw();
} ;
class sc_process_handle
{
publ ic:
sc_process_handle();
sc_process_handle( const sc_process_handl e& );
expl icit sc_process_handle( sc_obj ect* );
~sc_process_handle();
bool valid() const;
sc_process_handle& operator= ( const sc_process_handl e& );
bool operator== ( const sc_process_handl e& ) const;
bool operator!= ( const sc_process_handl e& ) const;
bool operator< ( const sc_process_handl e& ) const;
void swap( sc_process_handl e& );
const char* name() const;
sc_curr_proc_kind proc_kind() const;
const std::vector<sc_object* >& get_child_objects() const;
const std::vector<sc_event* >& get_child_events() const;
sc_object* get_parent_object() const;
sc_object* get_process_object() const;
bool dynamic() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


69
Copyright 2012 IEEE. All rights reserved.
bool terminated() const;
const sc_event& terminated_event() const;
void suspend ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void resume ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void disable ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void enable ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void kill ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void reset ( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
bool is_unwinding() const;
const sc_event& reset_event() const;
void sync_reset_on
( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
void sync_reset_off
( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
templ ate <typename T>
void throw_it( const T& user_defi ned_excepti on,
sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS );
} ;
sc_process_handle sc_get_current_process_handle();
bool sc_is_unwinding();
} // namespace sc_core
5.6.3 Constraints on usage
None. A process handl e may be created, copi ed, or del eted at any time during el aborati on or simulation. The
handl e may be vali d or i nval id.
5.6.4 Constructors
sc_process_handle();
The default constructor shall create an empty process handle. An empty process handle shall be an
invali d process handl e.
sc_process_handle( const sc_process_handl e& );
The copy constructor shall dupl icate the process handl e passed as an argument. The resul t wil l be
two handl es to the same underlyi ng process instance or two empty handl es.
expl icit sc_process_handle( sc_obj ect* );
I f the argument is a poi nter to a process i nstance, this constructor shall create a val id process handle
to the given process instance. Otherwi se, thi s constructor shal l create an empty process handle.
5.6.5 Member functions
bool valid() const;
Member f uncti on valid shall return trueif and only if the process handl e i s vali d.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


70
Copyright 2012 IEEE. All rights reserved.
sc_process_handle& operator= ( const sc_process_handl e& );
The assignment operator shal l dupl icate the process handle passed as an argument. The resul t wil l be
two handl es to the same underlyi ng process instance or two empty handl es.
bool operator== ( const sc_process_handl e& ) const;
The equali ty operator shal l return truei f and onl y if the two processhandles are both vali d and share
the same underlying process i nstance.
bool operator!= ( const sc_process_handl e& ) const;
The inequali ty operator shal l return false i f and onl y i f the two process handles are both vali d and
share the same underlying process instance.
bool operator< ( const sc_process_handl e& ) const;
The l ess-than operator shall def ine a str i ct weak or der i ng relation on the underl ying process
instances in the fol lowing sense. Gi ven three process handles H1, H2, and H3:
str i ct means that H1 < H1 shall return false(whether H1 i s vali d, i nvali d, or empty)
weak means that i f H1 and H2 are both handles (val id or i nval id) associated with the same
underlying process i nstance or both are empty handl es, then H1 < H2 shal l return falseand H2 < H1
shal l return false. Otherwise, if H1 and H2 are handl es associated wi th dif ferent underl ying process
instances or i f only one i s an empty handle, then exactly one of H1 < H2 and H2 < H1 shal l return
true.
orderi ng rel ati on means that i f H1 < H2 and H2 < H3, then H1 < H3 (whether H1, H2, or H3 are
val id or i nvali d).
Exampl e:
sc_process_handle a, b; // Two empty handles
sc_assert( !a.val id() && ! b.vali d() ); // Both are i nvali d
sc_assert( a != b );
sc_assert( ! (a < b) && ! (b < a) );

a = sc_spawn(...);
b = sc_spawn(...);
sc_assert( a != b );
sc_assert( (a < b) || (b < a) ); // Two handles to di ff erent processes

sc_process_handle c = b;
sc_assert( b == c );
sc_assert( ! (b < c) && ! (c < b) ); // Two handles to the same process
wait( a.terminated_event() & b.termi nated_event() );
sc_assert( (a < b) || (b < a) ); // Same orderi ng whether handl es are val id or not

if ( b.val id() ) // Handles may or may not have been inval idated
sc_assert( b == c );
else
sc_assert( b != c );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


71
Copyright 2012 IEEE. All rights reserved.
sc_assert( b.val id() == c.vali d() ); // I nvali dation is consistent
sc_assert( ! (b < c) && ! (c < b) ); // Two handles to the same process, whether vali d or not
sc_assert( c.terminated() );
voi d swap( sc_process_handl e& );
Member f uncti on swap shall exchange the process i nstances underl ying the process handl es * this
and the sc_process_handleargument. I f H1 < H2 prior to the cal l H1.swap(H2), then H2 < H1 af ter
the cal l. Either handle may be invali d.
Exampl e:
sc_process_handle a, b = sc_get_current_process_handle();
sc_assert( b.val id() );

a.swap( b );
sc_assert( a == sc_get_current_process_handl e() );
sc_assert( ! b.vali d() );
const char* name() const;
Member function nameshal l return the hierarchi cal name of the underl yi ng process instance. I f the
process handle i s i nvali d, member f uncti on name shal l return an empty stri ng, that is, a pointer to
the string . The implementation is only obliged to keep the returned string valid while the process
handl e i s vali d.
sc_curr_proc_kind proc_kind() const;
For a vali d process handle, member f unction proc_kind shall return one of the three val ues
SC_METHOD_PROC_, SC_THREAD_PROC_, or SC_CTHREAD_PROC_, depending on the
kind of the underlying process i nstance, that i s, method process, thread process, or cl ocked thread
process, respectively. For an invali d process handle, member functi on proc_kind shall return the
val ue SC_NO_PROC_.
const std::vector<sc_object* >& get_child_objects() const;
Member f uncti on get_child_objectsshall return a std::vector containi ng a pointer to every i nstance
of cl ass sc_object that is a chil d of the underlying process i nstance. Thi s shall include every
dynami c process i nstance that has been spawned during the executi on of the underl ying process
instance and has not yet been deleted, and any other appl icati on-def ined objects deri ved from class
sc_object created during the execution of the underlyi ng process i nstance that have not yet been
del eted. Processes that are spawned f rom chil d processes are not included (grandchil dren, as i t
were). I f the process handle i s i nval id, member function get_child_objects shall return an empty
std::vector.
This same functi on shal l be overridden i n any impl ementation-defi ned classes deri ved from
sc_object and associ ated wi th spawned and unspawned process i nstances. Such functions shal l have
identi cal behavi or provided that the process handl e i s vali d.
const std::vector<sc_event* >& get_child_events() const;
Member functi on get_child_eventsshall return a std::vector contai ni ng a poi nter to every object of
type sc_event that is a hierarchi cal ly named event and whose parent is the current process instance.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


72
Copyright 2012 IEEE. All rights reserved.
I f the process handle i s i nvali d, member functi on get_child_events shal l return an empty
std::vector.
This same functi on shal l be overridden i n any impl ementation-defi ned classes deri ved from
sc_object and associ ated wi th spawned and unspawned process i nstances. Such functions shal l have
identi cal behavi or provided that the process handl e i s vali d.
sc_object* get_parent_object() const;
Member functi on get_parent_object shall return a pointer to the modul e i nstance or process
instance from whi ch the underlyi ng process i nstance was spawned. I f the process handle i s invali d,
member function get_parent_object shall return the nul l poi nter. If the parent object i s a process
instance and that process has termi nated, get_parent_object shall return a pointer to that process
instance. A process i nstance shal l not be del eted (nor any associated process handles i nvali dated)
whil e the process has surviving chi ldren, but it may be deleted once all i ts chi ld objects have been
del eted.
sc_object* get_process_object() const;
I f the process handl e is vali d, member function get_process_object shall return a poi nter to the
process i nstance associ ated with the process handle. I f the process handle i s invali d, member
f uncti on get_process_object shall return the nul l poi nter. An appl icati on should test f or a null
pointer before dereferenci ng the poi nter. Moreover, an appl ication should assume that the poi nter
remains val id only until the call ing process suspends.
bool dynamic() const;
Member f unction dynamicshal l return truei f the underlying process instance is a dynamic process
and f alse i f the underlying process instance i s a stati c process. If the process handle is invali d,
member f uncti on dynamicshal l return the value false.
bool terminated() const;
Member f uncti on terminated shall return true if and onl y if the underlying process i nstance has
ter mi nated. A thread or clocked thread process i s ter mi nated af ter the point when control is returned
f rom the associ ated functi on. A process can al so be ter mi nated by call ing the kill method of a
process handl e associated wi th that process. This i s the only way i n which a method process can be
terminated. I f the process handle is empty, member functi on terminated shall return the val ue false.
When the underl ying process i nstance terminates, if the process instance has no surviving chi ldren,
an impl ementation may choose to i nvali date any associ ated process handles, but i t is not obl iged to
do so. An impl ementation shal l not i nvali date a process handl e whil e the process i nstance has child
objects. However, if an impl ementation chooses to invali date a process handl e, it shall inval idate
every process handle associated with the underlyi ng process i nstance at that time. I n other words, i t
shal l not be possi ble to have a vali d and an invali d handl e to the same underlyi ng process i nstance in
exi stence at the same time. Af ter the process instance has termi nated, f uncti on terminated wi ll
continue to return true, even i f the process handle becomes inval id. The process instance shal l
continue to exist as long as the process handl e is val id. Once al l the handles associ ated with a gi ven
process instance have been i nval idated, an impl ementation is f ree to del ete the process instance, but
it is not obli ged to do so. With respect to the value of functi on terminated and the ordering relati on
that def ines the behavior of operator< and method swap, in ef fect an inval id process handle
remai ns associ ated wi th a process i nstance even after that process instance has been del eted.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


73
Copyright 2012 IEEE. All rights reserved.
const sc_event& terminated_event() const;
Member functi on terminated_event shall return a reference to an event that i s noti fi ed when the
underlying process instance terminates. It shall be an error to cal l member function
terminated_event for an i nvali d process handl e.
5.6.6 Member functions for process control
The member f unctions of class sc_process_handledescri bed in this clause and its subcl auses are concerned
wi th process control . Exampl es of process control i nclude suspending, resumi ng, ki ll ing, or resetting a
process instance. Process control i nvolves a cal l i ng process control li ng a tar get process. I n each case, the
cal l i ng pr ocess cal ls a member f unction of a process handl e associated with the tar get pr ocess (or with i ts
parent obj ect, grandparent obj ect, and so f orth).
The call ing process and the target process may be disti nct process i nstances or may be the same process
instance. In the l atter case, certai n process control member f uncti ons are meaningless, such as havi ng a
process i nstance attempt to resume itsel f.
Several of the process control member functions are organized as complementary pai rs:
suspend and resume
disableand enable
sync_reset_on and sync_reset_off
kill
reset
throw_it
Each of the above member f uncti ons may be call ed where the underlying process instance is a method
process, a thread process, or a clocked thread process. There are certain caveats concerni ng the use of
suspend, resume, reset, and throw_it with cl ocked thread processes (see 5.2.12).
The disti nction between suspend/resume and disable/enable lies i n the sensi tivi ty of the target process
during the peri od while it is suspended or di sabled. Wi th suspend, the kernel keeps track of the sensitivity of
the target process whil e i t is suspended such that a rel evant event noti fi cation or time-out whi le suspended
would cause the process to become runnable immediatel y when resume is call ed. Wi th disable, the
sensitivity of the target process i s nul li fied whi le i t is suspended such that the process is not made runnable
by the call to enable, but only on the next relevant event notif icati on or ti me-out subsequent to the call to
enable. I n other words, with suspend/resume, the kernel keeps a record of whether the target process woul d
have awoken whi le i n f act being suspended, whereas with disable/enable, the kernel entirely i gnores the
sensitivity of the target process while disabled. Also see 5.2.12 regardi ng clocked thread processes.
Exampl e:
struct M1: sc_module
{
M1(sc_modul e_name _name)
{
SC_THREAD(ticker);
SC_THREAD(call ing);
SC_THREAD(target);
t = sc_get_current_process_handle();
}

sc_process_handle t;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


74
Copyright 2012 IEEE. All rights reserved.
sc_event ev;
void ti cker()
{
for (;;)
{
wait(10, SC_NS);
ev.noti fy();
}
}
void cal ling()
{
wait(15, SC_NS);
// Target runs at ti me 10 NS due to noti fi cati on
t.suspend();
wait(10, SC_NS);
// Target does not run at ti me 20 NS whil e suspended

t.resume();
// Target runs at ti me 25 NS when resume is call ed

wait(10, SC_NS);
// Target runs at ti me 30 NS due to noti fi cati on

t.di sable();
wait(10, SC_NS);
// Target does not run at ti me 40 NS whil e di sabled

t.enabl e();
// Target does not run at ti me 45 NS when enabl e i s call ed

wait(10, SC_NS);
// Target runs at ti me 50 NS due to noti fi cati on

sc_stop();
}
void target()
{
for (;;)
{
wait(ev);
cout << "Target awoke at " << sc_time_stamp() << endl;
}
}

SC_HAS_PROCESS(M1);
} ;
sync_reset_on and sync_reset_off provi de a procedural way of putti ng a process instance into and out of
the synchronous r eset state (see 5.6.6.3). Thi s i s equivalent i n eff ect to having specif ied a reset signal usi ng
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


75
Copyright 2012 IEEE. All rights reserved.
the member f unction reset_signal_is of cl ass sc_module or sc_spawn_options and that reset signal
attai ning i ts active val ue or the negation of its active val ue, respecti vel y.
Exampl e:
struct M2: sc_module
{
M2(sc_modul e_name _name)
{
SC_THREAD(ticker);
SC_THREAD(call ing);
SC_THREAD(target);
t = sc_get_current_process_handle();
}

sc_process_handle t;
sc_event ev;
void ti cker()
{
for (;;)
{
wait(10, SC_NS);
ev.noti fy();
}
}

void cal ling()
{
wait(15, SC_NS);
// Target runs at ti me 10 NS due to noti fi cati on

t.sync_reset_on();
// Target does not run at ti me 15 NS

wait(10, SC_NS);
// Target is reset at time 20 NS due to noti ficati on

wait(10, SC_NS);
// Target is reset again at ti me 30 NS due to notif ication

t.sync_reset_off ();
// Target does not run at ti me 35 NS

wait(10, SC_NS);
// Target runs at ti me 40 NS due to noti fi cati on

sc_stop();
}
void target()
{
cout << "Target call ed/reset at " << sc_ti me_stamp() << endl ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


76
Copyright 2012 IEEE. All rights reserved.
for (;;)
{
wait(ev);
cout << "Target awoke at " << sc_time_stamp() << endl;
}
}

SC_HAS_PROCESS(M2);
} ;
kill interrupts and i rrevocably terminates the target process. reset interrupts the target process and, in the
case of a thread process, cal ls the associated function again from the top. kill and reset both cause an
excepti on to be thrown wi thi n the target process, and that exception may be caught and handled by the
appl icati on. Both have i mmediate semanti cs such that the target process is kil led or reset before return f rom
the functi on cal l.
Exampl e:
struct M3: sc_module
{
M3(sc_modul e_name _name)
{
SC_THREAD(ticker);
SC_THREAD(call ing);
SC_THREAD(target);
t = sc_get_current_process_handle();
}

sc_process_handle t;
sc_event ev;
int count;
void ti cker()
{
for (;;)
{
wait(10, SC_NS);
ev.noti fy();
}
}

void cal ling()
{
wait(15, SC_NS);
// Target runs at ti me 10 NS due to noti fi cati on
sc_assert( count == 1 );

wait(10, SC_NS);
// Target runs again at ti me 20 NSdue to notif ication
sc_assert( count == 2 );

t.reset();
// Target reset immedi atel y at ti me 25 NS
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


77
Copyright 2012 IEEE. All rights reserved.
sc_assert( count == 0 );

wait(10, SC_NS);
// Target runs again at ti me 30 NSdue to notif ication
sc_assert( count == 1 );

t.ki ll();
// Target kil led i mmediatel y at time 35 NS
sc_assert( t.termi nated() );

sc_stop();
}
void target()
{
cout << "Target call ed/reset at " << sc_ti me_stamp() << endl ;
count = 0;
for (;;)
{
wait(ev);
cout << "Target awoke at " << sc_time_stamp() << endl;
++count;
}
}

SC_HAS_PROCESS(M3);
} ;
A process may be reset i n several ways: by a synchronous or asynchronous reset si gnal specif ied using
reset_signal_isor async_reset_signal_is, respecti vel y (see 5.2.13), by cal li ng sync_reset_on, or by cal li ng
reset. Whichever al ternati ve i s used, the reset acti on i tself is ul ti mately equi val ent to a call to reset.
throw_it permi ts a user-defi ned exception to be thrown withi n the target process.
For each of the nine member f uncti ons f or process control described in thi s cl ause and its subcl auses, i f the
process handle is invali d, the i mplementati on shal l generate a warni ng and the member f uncti on shal l return
immedi ately without having any other ef fect.
I n thi s cl ause, the phrase duri ng el abor ati on or befor e the pr ocess has fi r st executed shall encompass the
f ol lowi ng cases:
At any time during elaboration
From one of the callbacks before_end_of_elaboration, end_of_elaboration, or
start_of_simulation
During simulation but before the given process i nstance has executed for the f irst ti me
I n each case, i f the include_descendantsargument has the value SC_INCLUDE_DESCENDANTS, the
member f unction shall be appli ed to the associated process instance and recursively in bottom-up order to
all its chil dren in the object hierarchy that are also process instances, where each process i nstance shall in
turn act as the target process. I n other words, the member functi on shall be appl ied to the chi ldren,
grandchi ldren, great grandchi ldren, and so f orth, of the associated process instance, starti ng with the
deepest descendant, and fi ni shi ng wi th the associ ated process instance itsel f. If the include_descendants
argument has the val ue SC_NO_DESCENDANTS, the member f unction shall only be appli ed to the
associ ated process instance. There are no restricti ons concerni ng how this argument may be used across
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


78
Copyright 2012 IEEE. All rights reserved.
pai rs of cal ls to suspend-resume, disable-enable, or sync_reset_on-sync_reset_off. For example, it is
permi tted to suspend a process and al l of i ts descendants but only resume the process itself .
The member f unctions f or process control shal l not be call ed duri ng the update phase.
Beware that the rul es gi ven in the f ol lowi ng subclauses are to be understood al ongside the rules gi ven i n
5.6.6.11 concerni ng the i nteracti on between the member f uncti ons for process control , whi ch shal l take
precedence where appropriate.
5.6.6.1 suspend and resume
void suspend( sc_descendant_i ncl usi on_inf o i ncl ude_descendants = SC_NO_DESCENDANTS );
Member function suspend shal l suspend the target process instance such that it cannot be made
runnabl e agai n unti l it i s resumed by a cal l to member function resume, at the earliest (but see
5.6.6.11 for the rul es concerni ng reset). If the process instance i s i n the set of runnable processes, it
shal l be removed from that set immedi ately such that i t does not run in the current eval uation phase.
Whi le the process is suspended in this way, i f an event notif ication or time-out occurs to which the
process was sensi ti ve at the time the process was suspended, and i f resumeis call ed subsequently,
the process instance shal l become runnable in the evaluation phase i n which resume is call ed. In
other words, the impl ementation shall in eff ect add an i mplici t event to the sensitivity of the process
instance usi ng the event_and_l i st operator&, and shal l create an i mmediate notif ication f or this
event when resumeis cal led.
Call ing suspend on a process instance that i s al ready suspended shall have no eff ect on that
parti cul ar process instance, although i t may cause descendants to be suspended. Only a single call to
resumeis required to resume a suspended process instance.
I f a method process suspends itsel f, the associated function shal l run to the end bef ore returning
control to the kernel. If that same method process call s the resumemethod before returni ng control
to the kernel, the ef f ect of the call to suspendshall be removed as if suspend had not been cal led.
I f a thread process suspends itself , the process instance shall be suspended immedi atel y wi thout
control being returned f rom the suspend method back to the associ ated f unction.
I f suspend i s call ed f or a target process instance that is not suspended (meaning that suspend has
not been cal led) and i s in the synchronous reset state, the behavi or shal l be i mpl ementation-defi ned
(see 5.6.6.11).
Call ing suspend on a termi nated process i nstance shal l have no ef fect on that parti cul ar process
instance, although i t may cause the suspension of any non-termi nated descendant process i nstances.
Call ing suspend during el aborati on or bef ore the process has fi rst executed i s permitted. I f
dont_initializei s i n force, the implementation shal l i n eff ect add an impl icit event to the sensi ti vity
of the process i nstance using the event_and_l i st operator&, and shal l create an immedi ate
noti fi cati on for thi s event when resume i s cal led. Otherwise, the implementati on shall make the
process instance runnabl e immediatel y when resumeis cal led, in eff ect def erri ng initiali zation until
the process i nstance is resumed.
void resume( sc_descendant_i ncl usi on_inf o i ncl ude_descendants = SC_NO_DESCENDANTS);
Member functi on resume shall remove the ef fect of any previous cal l to suspend such that the
process instance shal l be made runnable i n the current eval uation phase if and only i f the sensi ti vi ty
of the process instance would have caused i t to become runnable whil e i t was in fact suspended. I f
the process i nstance was in the set of runnabl e processes at the time is was suspended, member
f uncti on resume shall cause the process i nstance to be made runnable in the current eval uati on
phase (but see 5.6.6.11 f or the rul es concerni ng the i nteraction between process control member
f uncti ons). I f the process i nstance was not i n the set of runnabl e processes at the ti me i t was
suspended and if there were no event notif ications or ti me-outs that woul d have caused the process
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


79
Copyright 2012 IEEE. All rights reserved.
instance to become runnable while it was i n f act suspended, member f uncti on resume shall not
make the target process i nstance runnable.
Member f uncti on resume shall restore the sensitivi ty of the target process as it was when suspend
was call ed.
I f a resumeis preceded by a reset, any event notif ications or time-outs that occurred before the ti me
of the reset shall be i gnored when determini ng the eff ect of resume.
A thread process shall be resumed f rom the executabl e statement foll owing the call to suspend. A
method process shall be resumed by cal li ng the associ ated f uncti on.
Call ing resumeon a process instance that i s not suspended shal l have no eff ect on that particul ar
process i nstance, al though it may cause suspended descendants to be resumed. As a consequence,
multipl e cal ls to resumefrom the same or from mul ti pl e processes wi thin the same eval uation phase
may cause the target process to run only once or to run more than once wi thin that eval uation phase,
depending on the precise order of process executi on.
I f mul ti pl e target processes become runnable within an evaluati on phase as a result of multipl e call s
to resume, they wil l be run i n an implementation-def ined order (see 4.2.1.2).
I f resume is cal led for a target process instance that i s both suspended (meaning that suspend has
been cal led) and disabl ed, the behavior shall be i mplementati on-def ined (see 5.6.6.11).
Call ing resume on a terminated process i nstance shall have no eff ect on that parti cular process
instance, although i t may cause any non-termi nated descendant process i nstances to be resumed.
Call ing resume during el aboration or bef ore the process has fi rst executed is permitted, in which
case the above rul es shal l appl y.
The function associated with any process instance can cal l suspend or resume: there i s no
obli gati on that a process instance be suspended and resumed by the same process instance.
5.6.6.2 disable and enable
void disable( sc_descendant_i ncl usi on_inf o i ncl ude_descendants = SC_NO_DESCENDANTS );
Member functi on disable shall disable the target process i nstance such that it cannot be made
runnabl e again unti l it is enabled by a cal l to member function enable, at the earli est. I f the di sabled
process instance is in the set of runnabl e processes, it shall not be removed from that set but shall be
all owed to run in the current eval uation phase. Whi le a process instance is disabl ed i n this way, any
events or time-outs to whi ch it is sensitive shal l be ignored f or that particular process i nstance such
that it wil l not be i nserted into the set of runnable processes. As a consequence of thi s rule, a
disabl ed process instance may run once and onl y once whil e it remai ns disabl ed, and then only if it
was already runnabl e at the time it was disabl ed.
Call ing disableon a process instance that is al ready di sabled shall have no ef f ect on that particular
process instance, al though i t may cause descendants to be disabl ed. Only a single call to enableis
required to enabl e a disabl ed process instance.
I f a process di sabl es i tself , whether it be a method process or a thread process the associated f uncti on
shal l conti nue to run to the poi nt where i t cal ls wait or to the end before returni ng control to the
kernel. If that same process calls the enablemethod before returning control to the kernel, the eff ect
of the cal l to disableshall be removed as if disablehad not been called.
I f disablei s cal led f or a target process instance that i s not di sabled and is waiting on a ti me-out (with
or wi thout an event or event l ist), the behavi or shall be i mplementati on-def ined (see 5.6.6.11).
Call ing disable on a termi nated process instance shall have no ef fect on that parti cul ar process
instance, although i t may cause any non-termi nated descendant process i nstances to be di sabled.
Call ing disable during el aboration or bef ore the process has f irst executed is permitted: i f the
process is already in the set of runnabl e processes at the time disablei s call ed, duri ng i nitiali zation,
f or example, i t shall be all owed to run.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


80
Copyright 2012 IEEE. All rights reserved.
void enable( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
Member f unction enable shal l remove the ef fect of any previous disable such that the process
instance can be made runnabl e by subsequent event noti fi cations or time-outs. Unli ke resume, an
enabled process shal l not become runnabl e due to event noti fi cation or ti me-outs that occurred whil e
it was disabled.
I f a ti me-out occurs whi le a process instance is disabled and that process i nstance is sensi ti ve to no
other events aside f rom the time-out itself , the process instance wi ll not run again (unl ess it is reset)
and the impl ementation may issue a warni ng.
When the enabled process instance next executes, if i t is a wai ti ng thread process it shal l execute
from the statement foll owing the call to wait at which i t was di sabl ed, and i f a method process i t
shal l execute by cal li ng the associ ated f unction.
Call ing enable on a process i nstance that is not di sabled shall have no eff ect on that particular
process i nstance, al though it may cause di sabl ed descendants to be enabled.
Call ing enable on a terminated process i nstance shall have no ef fect on that parti cul ar process
instance, although i t may cause any non-termi nated descendant process i nstances to be enabled.
Call ing enableduring elaborati on or before the process has f irst executed is permitted, in which case
the above rules shall apply.
I f disable is cal led duri ng el aboration and enable is onl y call ed after the initial ization phase, the
target process i nstance shal l not become runnabl e during the initiali zation phase, and shall not
become runnabl e when enableis cal led.
The functi on associated wi th any process instance can cal l disableor enable: there i s no obl igati on
that a process instance be disabl ed and enabl ed by the same process i nstance.
5.6.6.3 Member functions to reset processes
A process instance can be reset in one of three ways:
By a call to member function reset of a process handle associated wi th that process i nstance, which
shal l reset the target process i nstance i mmediatel y
By a reset signal specified using async_reset_signal_isattaining i ts reset value, at which ti me the
process instance shall be reset immedi ately (see 5.2.13)
By the process instance being resumed while it is in the synchronous r eset state, def ined as foll ows:
A process instance can be put into the synchronous r eset state in one of three ways:
By a call to member function sync_reset_on of a process handle associated with that process
instance
When any reset signal specified using reset_signal_is for that process instance attains its active
val ue
When any reset signal specified using async_reset_signal_is for that process i nstance attai ns its
active val ue
A process instance can onl y leave the synchronous reset state when all of the fol lowi ng appl y:
Member function sync_reset_off i s cal led or member functi on sync_reset_on has not yet been
cal led for a process handle associ ated with that process i nstance
Every reset signal specified using reset_signal_is for that process i nstance has the negati on of i ts
active val ue
Every reset signal specified using async_reset_signal_isf or that process i nstance has the negation
of i ts acti ve value
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


81
Copyright 2012 IEEE. All rights reserved.
I n each case, any resultant reset shal l be equi val ent to a call to member function reset, and hence, the event
returned by member function reset_event shall be noti fi ed.
Any given process i nstance can have mul tipl e resets specif ied usi ng reset_signal_is and
async_reset_signal_isi n addition to being the target of call s to member f uncti ons reset and sync_reset_on
of an associated process handle.
5.6.6.4 kill
void kill( sc_descendant_i ncl usi on_i nf o include_descendants = SC_NO_DESCENDANTS );
Member functi on kill shall kil l the target process i nstance such that an sc_unwind_exception shall
be thrown (see 5.6.6.6) for the ki lled process instance and the kill ed process instance shall not be
made runnable again duri ng the current si mulati on. A ki ll ed process shal l be termi nated.
I n the case of an exception thrown for a ki ll , member f unction is_reset of cl ass
sc_unwind_exceptionshall return the value false.
kill shal l have i mmediate eff ect; that is, the kil led process i nstance shall be removed f rom the set of
runnabl e processes, the cal l stack unwound, the process i nstance put into the termi nated state, and
the terminated event noti fi ed before the return from the kill functi on. Calls to kill can have side-
eff ects. I f a process kil ls another process, control shall return to the f uncti on that call ed kill. If a
process kil ls i tsel f, the statements fol lowi ng the cal l to kill shal l not be executed agai n during the
current si mulati on, and control shall return to the kernel .
Call ing kill on a terminated process instance shall have no eff ect on that particular process i nstance,
although it may cause any non-termi nated descendant process i nstances to be ki ll ed.
Call ing kill before the process has fi rst executed is permi tted, i n whi ch case the target process
instance shal l not be run during the current si mulati on.
I t shall be an error to call kill during el aboration, before the initial ization phase, or while the
simul ation is paused or stopped.
5.6.6.5 reset
void reset( sc_descendant_i ncl usi on_i nf o incl ude_descendants = SC_NO_DESCENDANTS);
Member f unction reset shal l reset the target process i nstance such that the process shall be removed
f rom the set of runnable processes, an sc_unwind_exception shal l be thrown f or the process
instance, any dynami c sensitivity associated with the process removed, and the static sensi ti vi ty
restored. The target process shal l not be termi nated. The process handl e shal l remain vali d. The
associ ated functi on shal l then be cal led agai n and, as a consequence, wi ll execute until it cal ls wait,
suspends itself , or returns.
reset shall have immedi ate ef fect; that i s, the target process i nstance shal l be removed f rom the set
of runnabl e processes, the cal l stack unwound, and the reset event notifi ed bef ore the return from the
reset function. Calls to reset can have si de-eff ects. In parti cular, care should be taken to avoi d
mutual recursi on between processes that reset one another. sc_unwind_exception may be caught
provided it i s i mmediatel y re-thrown.
I n the case of an sc_unwind_exception thrown for a reset, member f uncti on is_reset of cl ass
sc_unwind_exceptionshall return the value true.
A method process may be reset, although the associated function wil l not have a call stack to be
unwound except i n the case where a method process resets itself . When a method process is reset,
any dynamic sensitivity associ ated wi th the process shal l be removed, the static sensi ti vity restored,
and the associ ated f unction cal led again.
A thread or a method process i nstance may reset i tsel f (by a cal l to the reset method of an associated
process handle), i n whi ch case the call stack shal l be unwound i mmedi ately.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


82
Copyright 2012 IEEE. All rights reserved.
Call ing reset on a termi nated process i nstance shal l have no ef f ect on that particular process
instance, although i t may cause any non-termi nated descendant process i nstances to be reset.
Call ing reset bef ore the process has fi rst executed i s permitted, but i t shall have no eff ect other than
to noti fy the event returned by reset_event.
I t shall be an error to cal l reset duri ng elaborati on, bef ore the initiali zation phase, or whil e the
simul ation is paused or stopped.
5.6.6.6 Class sc_unwind_exception
Cl ass sc_unwind_exceptionis the type of the exception thrown by member functions kill and reset.
I n the case of a thread process suspended by a cal l to wait, or a thread or method process that ki ll s or resets
itsel f, the sc_unwind_exception shall cause the cal l stack of the associated function to be unwound and any
local objects to have thei r destructors call ed. I n the case of a method process, the associ ated f uncti on does
not have a call stack to be unwound unless the process ki lls or resets i tself , but a cal l to kill shall cause the
method process to be terminated nonetheless.
As a process i s being ki ll ed or reset, the unwinding of the call stack may have si de-ef fects, incl udi ng call s to
destructors f or local objects. Such side-eff ects shall not incl ude call s to wait or next_trigger, but they may
include call s to process control member functions f or other process i nstances, i ncl udi ng the call ing process
itsel f. In other words, calls to kill or reset can be nested (as can calls to throw_it, as descri bed in 5.6.6.10).
(The def aul t actions of the SystemC report handler f oll owing an error include the SC_THROW acti on,
which by def aul t throws an exception. An impl ementation i s obl iged to catch the sc_unwind_exception
bef ore havi ng the sc_report_handler throw another excepti on.)
The target process is permi tted to catch the sc_unwind_exception withi n i ts associated f unction body, in
which case i t shall re-throw the exception such that the impl ementation can properly execute the kil l or reset.
It shall be an error f or an appl ication to catch the sc_unwind_exception without re-throwi ng i t.
The catch block i n the target process shal l execute in the context of the target process, not the call ing
process. As a consequence, the f uncti on sc_get_current_process_handleshal l return a handle to the target
process instance when cal led from the catch bl ock.
virtual const char* what() const;
Member f uncti on what shall return an impl ementation-defi ned string descri bi ng the excepti on.
virtual bool is_reset() const;
Member f unction is_reset shal l return the val ue trueif the excepti on i s thrown by reset and falsei f
the exception is thrown by kill.
sc_unwind_exception();
sc_unwind_exception( const sc_unwi nd_excepti on& );
virtual ~sc_unwind_exception();
This exception shal l onl y be thrown by the kernel . Hence, the constructors and destructor shal l be
protected members.
Exampl e:
SC_MODULE(m)
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


83
Copyright 2012 IEEE. All rights reserved.
SC_CTOR(m)
{
SC_THREAD(run);
}
void run()
{
try {
...
}
catch (const sc_unwind_exception& ex) {
// Perform clean-up
if (ex.is_reset())
...
else
...
throw ex;
}
}
...
} ;
5.6.6.7 is_unwinding
bool is_unwinding() const;
Member f unction is_unwindingshal l return the val ue true f rom the point when the kernel throws
an sc_unwind_exceptionto the poi nt when the kernel catches that same sc_unwind_exception, and
otherwi se shall return the value false. Hence, is_unwindingshall return truewhen call ed duri ng the
unwinding of the cal l stack fol lowing a call to kill or reset, but not f ollowi ng a call to throw_it. The
intent is that this member f uncti on can be call ed f rom the destructor of a local object defi ned wi thi n
the function associ ated wi th a process i nstance, where it can be used to diff erenti ate between the
case where a process is ki ll ed or reset and the end of simul ation.
I f call ed for an invalid process handle, the impl ementation shal l generate a warning and
is_unwindingshall return the value false.
There also exists a non-member f uncti on that cal ls is_unwindingf or the currently executing process
(see 5.6.8).
5.6.6.8 reset_event
const sc_event& reset_event() const;
Member functi on reset_event shall return a ref erence to an event that is notif ied whenever the target
process instance i s reset, whether that be through an expl icit cal l to member f uncti on reset, through
a process instance being resumed whi le i t is in the synchronous reset state, or through a reset signal
attai ning i ts acti ve value. The reset event shal l be schedul ed usi ng an i mmediate notif ication in the
eval uation phase i n which the expli cit or implici t cal l to reset occurs. I t shal l be an error to call
member f uncti on reset_event for an i nvali d process handle.
5.6.6.9 sync_reset_on and sync_reset_off
void sync_reset_on( sc_descendant_i ncl usion_inf o i ncl ude_descendants = SC_NO_DESCENDANTS );
void sync_reset_off( sc_descendant_i ncl usi on_inf o include_descendants = SC_NO_DESCENDANTS );
Member f unction sync_reset_on shal l cause the target process instance to enter the synchronous
r eset state. Whi le i n the synchronous reset state, a process instance shall be reset each ti me it is
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


84
Copyright 2012 IEEE. All rights reserved.
resumed, whether due to an event noti f ication or to a ti me-out. The call to sync_reset_on shall not
itsel f cause the process to be reset immedi atel y; the process shal l onl y be reset each ti me it is
subsequentl y resumed. Being reset in this sense shal l have the same ef fect as woul d a cal l to the
reset method, as descri bed above.
Member f uncti on sync_reset_off shall cause the target process instance to leave the synchronous
r eset state (unl ess any reset signal specif ied using reset_signal_isor async_reset_signal_isfor that
process i nstance has i ts acti ve val ue), thereby reversing the ef f ect of any previ ous call to
sync_reset_on for that process i nstance. sync_reset_off shall not modif y the eff ect of any reset
signal and shal l not modif y the ef f ect of any expli cit call to the reset method.
As a consequence of the above rul es, if a cal l to sync_reset_on is f ollowed by a call to
sync_reset_off bef ore a parti cul ar process i nstance has been resumed, that process i nstance cannot
have been reset due to the sync_reset_on cal l, although it may have been reset due to the ef fect of a
reset si gnal (specif ied using reset_signal_isor async_reset_signal_is) or a cal l to the reset method.
I t is permi ssibl e to cal l sync_reset_on and sync_reset_off wi th the include_descendantsargument
havi ng the val ue SC_INCLUDE_DESCENDANTSand where the descendants are a mixture of
method and thread processes; the appropri ate action shall be taken for each descendant process
instance accordi ng to whether i t i s a method process or a thread process.
Call ing sync_reset_on for a process instance that is al ready i n the synchronous reset state shal l have
no ef fect on that parti cul ar process i nstance, although it may cause descendants to enter the
synchronous reset state. Only a si ngl e cal l to sync_reset_off is required for a particular process
instance to l eave the synchronous reset state (assuming there is no reset signal active).
Call ing sync_reset_off f or a process instance that i s not currently i n the synchronous reset state shal l
have no eff ect on that particular process i nstance, although i t may cause descendants to l eave the
synchronous reset state.
A process instance may call sync_reset_on or sync_reset_off wi th itself as the target. As a
consequence of the above rules, the eff ect of the call will onl y be visible the next time the process
instance i s resumed.
I f sync_reset_on i s call ed f or a target process i nstance that i s not in the synchronous reset state and
is suspended (meaning that suspendhas been call ed), the behavi or shal l be impl ementation-defi ned
(see 5.6.6.11).
Call ing sync_reset_on or sync_reset_off for a termi nated process instance shal l have no ef fect on
that particul ar process i nstance, al though it may cause descendant process instances to enter or l eave
the synchronous reset state.
Call ing sync_reset_on or sync_reset_off during el aboration or bef ore the process has f irst executed
is permitted, i n which case the target process instance shall enter or l eave the synchronous reset state
accordi ngl y. Bei ng in the synchronous reset state shal l have no eff ect on the i nitiali zati on of a
process instance; that is, the process instance shal l be resumed during the f irst eval uati on phase and
shal l run up to the point where it either returns or calls wait. I f a process i nstance is sti ll in the
synchronous reset state when it i s f irst resumed (f rom a cal l to wait), then it shal l be reset as
descri bed above.
The f uncti on associated wi th any process i nstance can call sync_reset_on or sync_reset_off: there
is no obl igati on that sync_reset_on and sync_reset_off shoul d be cal led by the same process
instance.
5.6.6.10 throw_it
templ ate <typename T>
void throw_it( const T& user_defi ned_excepti on,
sc_descendant_inclusion_info include_descendants = SC_NO_DESCENDANTS);
Member functi on throw_it shall throw an excepti on wi thin the target process instance. The
excepti on to be thrown shall be passed as the f irst argument to f unction throw_it. The exception
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


85
Copyright 2012 IEEE. All rights reserved.
shal l be thrown in the context of the target process, not i n the context of the cal ler. Excepting the
special case where a process throws an exception to i tsel f, this shall require two context switches:
f rom the cal ler to the target process and from the target process back to the cal ler.
I t is recommended that the exception bei ng thrown shoul d be derived f rom class std::exception, but
an appli cati on may throw an excepti on not derived from cl ass std::exception.
Any dynamic sensitivi ty associated with the target process instance shall be removed and the stati c
sensitivity restored. The target process instance shal l not be termi nated by vi rtue of the f act that
throw_it was cal led, although a thread process may immedi atel y terminate i f control i s returned
f rom the associ ated f uncti on af ter the exception has been caught.
throw_it shall have immedi ate eff ect; that is, control shall be passed f rom the call er to the target
process and the excepti on thrown and caught bef ore the return from the throw_it f unction. Call s to
throw_it can have si de-ef f ects.
The target process i nstance shal l catch the exception i n its associ ated f uncti on. It shall be an error for
the target process i nstance not to catch the exception. Af ter catching the exception, the associated
f uncti on may return (and thus terminate i n the case of a thread process) or may call wait. I t shal l be
an error f or the target process to throw another exception whil e handli ng the f irst exception.
I f a process throws an exception to another process, control shall return to the f uncti on that cal led
throw_it. If a process throws an excepti on to itsel f, f uncti on throw_it does not return control to the
cal ler because its executi on i s i nterrupted by the exception, but control shal l pass to a catch block in
the functi on associ ated with the process.
The act of catching and handli ng the exception may have si de-ef fects, incl udi ng call s to destructors
f or l ocal obj ects. Such si de-ef f ects shall not i ncl ude call s to wait or next_trigger, but they may
include call s to process control member functi ons for other process i nstances, including the cal li ng
process itsel f. I n other words, call s to throw_it can be nested (as can cal ls to kill or reset, as
described i n 5.6.6.6).
throw_it is only appli cabl e when the target is a non-terminated thread process. Calls to throw_it
where the target process i nstance i s a method process or a termi nated process are permitted and shal l
have no eff ect except that an impl ementation may issue a warni ng. This shall i ncl ude the case where
a method process throws an exception to i tsel f. In parti cul ar, i t is permissible to call throw_it with
the include_descendantsargument having the value SC_INCLUDE_DESCENDANTSand where
the descendants are a mi xture of method and thread processes, some of whi ch may have terminated;
the appropri ate acti on shall be taken f or each descendant process i nstance. If the target process is a
non-terminated method process, that process shall not be terminated by the cal l to throw_it.
throw_it is only appl icabl e when the target process instance has been suspended duri ng executi on,
that i s, has cal led wait or has been the target of a call to suspend or disable. A call to throw_it in
any other context during si mulati on shall have no ef f ect except that an implementation may generate
a warning. In parti cul ar, a call to throw_it during si mulation before the target process has fi rst
executed shall have no ef f ect except to generate a warni ng.
I t shall be an error to cal l throw_it during elaborati on, bef ore the initiali zation phase, or whi le the
simul ation is paused or stopped.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


86
Copyright 2012 IEEE. All rights reserved.
5.6.6.11 Interactions between member functions for process control
I n Table 2, the phrase The curr ent eval uati on phase means that the ef fect on the target process becomes
visibl e duri ng the evaluation phase in which the process control member f uncti on i s call ed. For exampl e, a
cal l to suspend coul d remove the target process f rom the set of runnable processes, and an immedi ate
notif icati on fol lowing a call to enablecould cause the target process to run in the current eval uati on phase.
The next eval uati on phase implies that disable would not prevent the target process f rom running i n the
current eval uati on phase, but i t would prevent the target process f rom running i n the subsequent eval uation
phase. Immedi ate means that an exception i s thrown and any associ ated actions are completed in the target
process bef ore return to the call er.
As described above, member functi ons kill and reset each achi eve thei r eff ect by throwing an object of class
sc_unwind_exception, whi le member function throw_it throws an excepti on of a user-defi ned cl ass. Cal ls
to kill, reset, and throw_it may be nested such that a process catching an exception may kill or reset another
process instance or may throw an excepti on i n another process i nstance before i tself returni ng control to the
kernel . Si mil arly, the destructor of an object that i s going out-of-scope during stack unwi ndi ng (as a result of
an sc_unwind_exceptionhaving been thrown) may itself ki ll or reset another process instance or may throw
an excepti on in another process instance. It i s possibl e that such a chain of cal ls can get interrupted by a
process instance kil li ng or resetti ng itself , either directl y or indi rectly. For example, if a given process
instance attempts to kil l al l the descendants of i ts parent process wi th the call
handle.kill(SC_I NCLUDE_DESCENDANTS), the descendant process i nstances wi ll be kil led one-by-
one until the call ing process instance is reached, at which point the cal ler itsel f wil l be kil led and the cal l
stack unwound.
Care should be taken to avoi d mutual recursi on between processes that ki ll or reset one another, as such
mutual recursion can resul t i n stack overf low.
The rel ative priorities of the process control member functions are gi ven bel ow, ordered f rom highest
pri ority to lowest priority:
1) kill, reset, throw_it
2) disable, enable
3) suspend, resume
4) sync_reset_on, sync_reset_off
Table 2When process control member functions take effect
Member function Whenit takeseffect on thetarget processinstance
suspend The current eval uati on phase
resume The current eval uati on phase
disable The next eval uati on phase
enable The current eval uati on phase
kill I mmedi ate
reset I mmedi ate
throw_it I mmedi ate
sync_reset_on The current eval uati on phase
sync_reset_off The current eval uati on phase
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


87
Copyright 2012 IEEE. All rights reserved.
For each process i nstance, the impl ementation shall in ef fect maintai n three i ndependent fl ags to track the
state of call s to the member functions disable/enable, suspend/resume, and sync_reset_on/sync_reset_off,
and shal l then act accordi ng to the relati ve priority of those cal ls as l isted above. Each of these three f lags
shal l be set and cleared by call s to the correspondi ng pai r of member functions irrespecti ve of the val ues of
the remai ning two fl ags and i rrespective of the f act that certain i nteractions between the process control
member functions are impl ementation-defi ned. For exampl e, given two successive call s to resume with no
interveni ng call to suspend, the second cal l to resumewould have no eff ect, irrespecti ve of any intervening
cal ls to disableor enable.
Member functi ons kill, reset, and throw_it have i mmediate semantics that are executed immedi atel y even if
the target process instance is di sabled, suspended, or in the synchronous reset state. I n such a case, the target
process shal l remain di sabled, suspended, or i n the synchronous reset state after the immedi ate action has
been completed. For example, a call to throw_it where the target process was di sabled mi ght cause the
target process to wake up, catch the exception, call wait withi n i ts catch bl ock, and f inall y yield control back
to the kernel , all the whi le remaining in the disabl ed state.
The behavior of certai n i nteracti ons between the process control member f unctions shall be impl ementation-
def ined, as fol lows:
a) I f resumei s call ed for a target process i nstance that i s currently both suspended and disabl ed, the
behavior shall be impl ementation-defi ned (where suspended means suspend has been cal led and
disabl ed means disablehas been cal led).
b) I f sync_reset_on i s call ed or if a synchronous or asynchronous reset signal attains its active value
f or a target process i nstance that is currently both suspended and not in the synchronous reset state,
the behavior shal l be impl ementation-defi ned.
c) I f suspend i s cal led for a target process instance that is currentl y both in the synchronous reset state
(whether by means of a cal l to sync_reset_on or by means of a synchronous or asynchronous reset
signal having attai ned its acti ve value) and not suspended, the behavi or shall be i mplementati on-
def ined.
d) I f disable is called f or a target process i nstance that is currentl y both not disabl ed and wai ti ng on a
ti me-out (whether or not the ti me-out is accompanied by an event or an event l ist), the behavior shall
be i mplementati on-def ined.
If reset i s cal led whil e a target process instance i s suspended, reset shal l remove the dynami c sensitivity of
the target process such that any event noti fi cati on or time-out that occurred bef ore the time of the reset wi ll
be ignored when determini ng the behavi or of a subsequent cal l to resume f or that same target process. I n
other words, a reset shall wipe the sl ate cl ean when determi ni ng the behavior of resume.
I t shall be an error to cal l the three member f uncti ons with i mmediate semantics duri ng elaboration, before
the i ni ti al izati on phase, or whi le the simul ation i s paused or stopped, but the remai ni ng member functi ons
may be cal led whil e i n those states.
NOTEThe intent of making certain interactions between the process control member f uncti ons i mpl ementation-
def ined i s to shi el d the user from surprisi ng behavior whi le al so al l owi ng for more speci f i c semanti cs to be def i ned i n the
f uture as and when the use cases f or the process control member f uncti ons are cl ari f i ed.
Exampl e:
sc_process_handle h;
...
t.sync_reset_on(); // Target process put into the synchronous reset state
A(); // Bl ocking cal l
t.suspend(); // Target process suspended
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


88
Copyright 2012 IEEE. All rights reserved.
B(); // Blocking call
t.di sable(); // Target process disabl ed
C(); // Blocking call
t.reset(); // Target process immediatel y reset but sti ll di sabled
// Stati c sensitivi ty restored for target process
D(); // Blocking call
t.enabl e(); // Target process enabled but stil l suspended
E(); // Blocking call
t.di sable(); // Target process disabl ed
F(); // Blocking call
t.enabl e(); // Target process enabled but stil l suspended
G(); // Blocking call
t.resume(); // Target process resumed but sti ll i n the synchronous reset state
// Target process is made runnabl e i f sensitive to an event notifi ed by E or G
// Target process not made runnabl e i f sensitive to an event notif ied by A, B, C, D,
// or F
5.6.7 sc_get_current_process_handle
sc_process_handle sc_get_current_process_handle();
The val ue returned f rom functi on sc_get_current_process_handleshall depend on the context i n which i t is
cal led. When call ed during elaborati on from the body of a module constructor or from a f unction called f rom
the body of a module constructor, sc_get_current_process_handleshall return a handl e to the spawned or
unspawned process instance most recentl y created within that module, i f any. When cal led f rom one of the
cal lbacks before_end_of_elaboration or end_of_elaboration, sc_get_current_process_handle shall
return a handle to the spawned or unspawned process instance most recentl y created wi thin that specif ic
cal lback f uncti on, i f any. I f the most recently created process i nstance was not withi n the current modul e, or
in the case of before_end_of_elaboration or end_of_elaboration was not created within that speci fi c
cal lback, an implementati on may return either a handl e to the most recentl y created process instance or an
invali d handle. When call ed f rom sc_main duri ng elaborati on or from the cal lback start_of_simulation,
sc_get_current_process_handlemay return either a handle to the most recently created process instance or
an inval id handl e. When cal led during simul ation, sc_get_current_process_handleshal l return a handle to
the currently executing spawned or unspawned process i nstance, if any. I f there i s no such process instance,
sc_get_current_process_handle shall return an i nvali d handl e. When cal led from sc_main duri ng
simul ation, sc_get_current_process_handleshall return an invalid handl e.
Exampl e:
SC_MODULE(Mod)
{
...
SC_CTOR(Mod)
{
SC_METHOD(Run);
sensitive << i n;
sc_process_handle h1 = sc_get_current_process_handle(); // Returns a handl e to process Run
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


89
Copyright 2012 IEEE. All rights reserved.
}
void Run()
{
sc_process_handle h2 = sc_get_current_process_handle(); // Returns a handl e to process Run
if (h2.proc_ki nd() == SC_METHOD_PROC_)
... // Runni ng a method process
sc_object* parent = h2.get_parent_object(); // Returns a pointer to the
// modul e instance
if (parent)
{
handl e = sc_process_handle(parent); // Invalid handle - parent is not a process
if (handl e.vali d())
... // Executed if parent were a
// val id process
}
}
...
} ;
5.6.8 sc_is_unwinding
bool sc_is_unwinding();
Function sc_is_unwinding shall return the value returned f rom member function is_unwinding of the
process handle returned f rom sc_get_current_process_handle. In other words, sc_is_unwinding shal l
return trueif and only if the call er is currentl y the target process i nstance of a call to kill or reset.
Exampl e:
struct wai t_on_exit
{
~wai t_on_exi t() {
if ( ! sc_i s_unwinding() ) // needed, because we mi ght get ki ll ed
wait( 10, SC_NS ) ; // ... and this wai t would be ill egal
}
} ;
void some_module::some_process()
{
whil e( true )
{
try {
wait_on_exi t w; // local obj ect, destroyed before catch
// ...
} catch( const sc_unwi nd_excepti on& ) {
// some other cleanup
throw;
}
}
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


90
Copyright 2012 IEEE. All rights reserved.
5.7 sc_event_finder and sc_event_finder_t
5.7.1 Description
An event fi nder is a member function of a port class with a return type of sc_event_finder&. When a port
instance is bound to a channel instance contai ning mul ti ple events, an event fi nder permi ts a speci fi c event
f rom the channel to be retrieved through the port instance and added to the static sensi ti vi ty of a process
instance. sc_event_finder_t is a templ ated wrapper for class sc_event_finder, where the templ ate parame-
ter is the i nterf ace type of the port.
An event f inder f unction is cal led when creati ng stati c sensitivity to events through a port. Because port
binding may be deferred, it may not be possi bl e for the i mplementati on to retri eve an event to whi ch a pro-
cess is to be made sensitive at the ti me the process instance is created. Instead, an appl icati on shoul d call an
event fi nder f unction, in which case the i mplementati on shall defer the adding of events to the stati c sensitiv-
ity of the process until port binding has been completed. These def erred acti ons shal l be compl eted by the
impl ementation bef ore the call backs to f unction end_of_elaboration.
I f an event f inder f unction i s call ed for a mul ti port bound to more than one channel instance, the events f or
all such channel i nstances shall be added to the stati c sensitivi ty of the process.
5.7.2 Class definition
namespace sc_core {
class sc_event_finder i mpl ementati on-defi ned ;
templ ate <cl ass I F>
class sc_event_finder_t
: publi c sc_event_fi nder
{
publ ic:
sc_event_finder_t( const sc_port_base& port_, const sc_event& (I F::* event_method_) () const );
// Other members
i mpl ementati on-defi ned
} ;
} // namespace sc_core
5.7.3 Constraints on usage
An appl icati on shall onl y use class sc_event_finder as the return type (passed by ref erence) of a member
f uncti on of a port class, or as the base cl ass f or an appli cati on-specif ic event f inder class template that may
possess additional template parameters and event method parameters.
An appli cation shal l only use class sc_event_finder_t<interface> in constructi ng the obj ect returned f rom
an event fi nder.
An event fi nder shall have a return type of sc_event_finder& and shall return an obj ect of cl ass
sc_event_finder_t<interface> or an appli cation-specif ic event f inder class template, where:
a) i nter face shal l be the name of an interface to which said port can be bound, and
b) the fi rst argument passed to the constructor f or sai d object shal l be the port obj ect itself , and
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


91
Copyright 2012 IEEE. All rights reserved.
c) the second argument shall be the address of a member f uncti on of sai d interface. The event found by
the event f inder is the event returned by this functi on.
An event f inder member f uncti on may only be call ed when creati ng the stati c sensi ti vity of a process usi ng
operator<<, function set_sensitivity, or macro SC_CTHREAD. An event f inder member function shall
only be call ed during elaborati on, either f rom a constructor or f rom the before_end_of_elaboration call -
back. An event fi nder member f uncti on shall not be cal led from the end_of_elaboration callback or duri ng
simul ation. Instead, an appli cati on may make a process directly sensitive to an event.
I n the case of a mul ti port, an event f inder member f unction cannot f ind an event from an i ndi vidual channel
instance to which the multiport is bound using an index number. An appl icati on can work around this
restricti on by getti ng the events f rom the individual channel i nstances in the end_of_elaboration cal lback
after port bi ndi ng i s complete (see exampl e below).
Exampl e:
#include "systemc.h"
class if _cl ass
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual const sc_event& ev_f unc() const = 0;
...
} ;
class chan_cl ass
: publi c i f_class, publ ic sc_pri m_channel
{
publ ic:
virtual const sc_event& ev_f unc() const { return an_event; }
...
pri vate:
sc_event an_event;
} ;
templ ate<int N = 1>
class port_class
: publi c sc_port<if _cl ass,N>
{
publ ic:
sc_event_f inder& event_f inder() const
{
return * new sc_event_f inder_t<i f_class>( * this , & if _cl ass::ev_func );
}
...
} ;
SC_MODULE(mod_cl ass)
{
port_class<1> port_var;
port_class<0> mul ti port;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


92
Copyright 2012 IEEE. All rights reserved.
SC_CTOR(mod_class)
{
SC_METHOD(method);
sensitive << port_var.event_fi nder(); // Sensitive to chan_cl ass::an_event
}
void method();
...
void end_of_elaboration()
{
SC_METHOD(method2);
f or (i nt i = 0; i < multiport.si ze(); i ++)
sensitive << multiport[ i] ->ev_func(); // Sensi tive to chan_cl ass::an_event
}
void method2();
...
} ;
NOTEFor particular examples of event f i nders, ref er to the f uncti ons posand negof cl ass sc_in<bool> (see 6.9).
5.8 sc_event_and_list and sc_event_or_list
5.8.1 Description
The cl asses sc_event_and_list and sc_event_or_list are used to represent expli cit event l ist objects which
may be constructed and mani pul ated pri or to bei ng passed as arguments to the functions next_trigger (see
5.2.17) and wait (see 5.2.18). An event li st object shall store pointers or ref erences to zero or more event
objects. An event l ist may contain mul ti pl e references to the same event obj ect. The order of the events
wi thin the event l ist shall have no eff ect on the behavior of the event l ist when it i s used to create dynamic
sensitivity.
5.8.2 Class definition
namespace sc_core {
class sc_event_and_list
{
publ ic:
sc_event_and_list();
sc_event_and_list( const sc_event_and_l ist& );
sc_event_and_list( const sc_event& );
sc_event_and_l ist& operator= ( const sc_event_and_l ist& );
~sc_event_and_list();
int size() const;
void swap( sc_event_and_li st& );
sc_event_and_l ist& operator&= ( const sc_event& );
sc_event_and_l ist& operator&= ( const sc_event_and_l ist& );
sc_event_and_expr

operator& ( const sc_event& ) const;


sc_event_and_expr

operator& ( const sc_event_and_li st& ) const;


} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


93
Copyright 2012 IEEE. All rights reserved.
class sc_event_or _li st
{
publ ic:
sc_event_or _li st();
sc_event_or _li st( const sc_event_or_l ist& );
sc_event_or _li st( const sc_event& );
sc_event_or_l ist& oper ator = ( const sc_event_or_li st& );
~sc_event _or _li st ();
int size() const;
void swap( sc_event_or_li st& );
sc_event_or_l ist& oper ator |= ( const sc_event& );
sc_event_or_l ist& oper ator |= ( const sc_event_or_l ist& );
sc_event_or _expr

oper ator | ( const sc_event& ) const;


sc_event_or _expr

oper ator | ( const sc_event_or_li st& ) const;


} ;
} // namespacesc_core
5.8.3 Constraints and usage
The intended usage for obj ects of class sc_event_and_li st and sc_event _or _li st i sthat they are passed as
arguments to the functions wait and next_tr igger . Unl ike the case of event expressi on obj ects, whi ch are
del eted automaticall y by the implementation (see 5.9.3), the appl icati on shall be responsi bl e for del eting
event l ist objects whenthey areno longer required. Theappli cation shall beresponsi bl efor ensuring that an
event li st obj ect i sstil l val id (that i s, hasnot been destroyed) when aprocessinstanceresumesor i striggered
asadi rect result of thenoti ficati onof oneor moreeventsi n theevent li st. If theevent l ist object hasal ready
been destroyed at thi spoint, thebehavior of thei mplementati onshal l beundefi ned.
5.8.4 Constructors, destructor, assignment
sc_event _and_li st();
sc_event _or _li st();
Each defaul t constructor shal l construct an empty event li st obj ect. It shall be an error to pass an
empty event l ist object asan argument to thefunctionswait or next_tr igger .
sc_event _and_li st( const sc_event_and_l ist& );
sc_event _or _li st( const sc_event_or_l ist& );
sc_event_and_l ist& oper ator = ( const sc_event_and_li st& );
sc_event_or_l ist& oper ator = ( const sc_event_or_li st& );
Thecopy constructors and assi gnment operators shall permi t event l ist objectsto bei nitiali zed and
assignedby theappli cation.
sc_event _and_li st( const sc_event& );
sc_event _or _li st( const sc_event& );
These constructors shall construct event list obj ects contai ni ng the si ngl e event passed as an argu-
ment totheconstructor.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


94
Copyright 2012 IEEE. All rights reserved.
~sc_event_and_list();
~sc_event_or_list();
An event li st object may be constructed as a stack or as a heap vari abl e. In the case of the heap, the
appl icati on is responsibl e f or del eting an event l ist object when it i s no longer required.
5.8.5 Member functions and operators
int size() const;
Member f uncti on sizeshall return the number of events in the event l ist. Any dupli cate events in the
event l ist shal l not count toward the val ue of size.
Exampl e:
sc_event ev;
sc_event_or_l ist l ist = ev | ev;
sc_assert( l ist.size() == 1 );
void swap( sc_event_and_li st& );
void swap( sc_event_or_li st& );
Member functi on swapshall exchange the current event list object *thiswith the event li st passed as
an argument.
sc_event_and_l ist& operator&= ( const sc_event& );
sc_event_and_l ist& operator&= ( const sc_event_and_l ist& );
sc_event_and_expr

operator& ( const sc_event& ) const;


sc_event_and_expr

operator& ( const sc_event_and_li st& ) const;


sc_event_or_l ist& operator|= ( const sc_event& );
sc_event_or_l ist& operator|= ( const sc_event_or_l ist& );
sc_event_or _expr

operator| ( const sc_event& ) const;


sc_event_or _expr

operator| ( const sc_event_or_li st& ) const;


Each of these operators shal l append the event or event l ist passed as an argument to the current
event l ist obj ect *this, and shal l return the resultant el ongated event l ist as the val ue of the operator.
I n the case of the assi gnment operators &= and |=, the operator shal l return a reference to the current
object, which shal l have been modif ied to contain the el ongated event l ist. I n the case of the remai n-
ing operators & and |, the current object *thisshall not be modif ied.
Exampl e:
struct M: sc_module
{
sc_port<sc_si gnal_i n_i f<i nt>, 0> p; // Mul ti port

M(sc_module_name _name)
{
SC_THREAD(T);
}

sc_event_or_l ist all _events() const
{
sc_event_or_l ist or_l ist;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


95
Copyright 2012 IEEE. All rights reserved.
for (i nt i = 0; i < p.size(); i ++)
or_l ist |= p[i]->default_event();
return or_li st;
}

sc_event event1, event2;
...

void T()
{
for (;;)
{
wait( all _events() );
...
sc_event_and_l ist l ist;
sc_assert( l ist.size() == 0 );

li st = li st & event1;
sc_assert( l ist.size() == 1 );

li st &= event2;
sc_assert( l ist.size() == 2 );

wait(l ist);
sc_assert( l ist.size() == 2 );
...
}
}
SC_HAS_PROCESS(M);
} ;
5.9 sc_event_and_expr

and sc_event_or_expr

5.9.1 Description
Thecl assessc_event_and_expr

and sc_event_or _expr

provi dethe& and | operatorsused to construct the


event expressi onspassed as argumentsto thefunctions wait (see5.2.17) and next _tr igger (see5.2.18). An
event expressi on object shal l storepointersor referencesto zero or moreevent obj ects. An event expressi on
may contain multipl e references to the same event object. The order of the events within the event
expression shal l have no effect on the behavior of theevent expression when it is used to create dynamic
sensitivity.
5.9.2 Class definition
namespacesc_core{
class sc_event_and_expr

{
publ ic:
oper ator const sc_event_and_l ist & () const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


96
Copyright 2012 IEEE. All rights reserved.
// Other members
i mpl ementati on-defi ned
} ;
sc_event_and_expr

oper ator & ( sc_event_and_expr

, sc_event const& );
sc_event_and_expr

oper ator & ( sc_event_and_expr

, sc_event_and_l ist const& );


classsc_event_or _expr

{
publ ic:
oper ator const sc_event _or _li st & () const;
// Other members
i mpl ementati on-defi ned
} ;
sc_event_or _expr

oper ator | ( sc_event_or _expr

, sc_event const& );
sc_event_or _expr

oper ator | ( sc_event_or _expr

, sc_event_or_l ist const& );


} // namespacesc_core
5.9.3 Constraints on usage
An appl icati on shal l not expl icitly createan object of cl ass sc_event_and_expr

or sc_event_or _expr

. An
appl icati on wishi ng to create expl ici t event l ist obj ects should use the classes sc_event_and_li st and
sc_event_or _li st.
Cl asses sc_event_and_expr

and sc_event_or _expr

are the return types of oper ator & and oper ator |,
respectivel y, of cl asses sc_event, sc_event _and_li st, and sc_event _or _li st .
The existence of the type conversi on operators from type sc_event_and_expr

to type const
sc_event_and_li st & and fromtypesc_event_or _expr

to typeconst sc_event_or_l ist & all ow expressi ons


of type sc_event_and_expr

and sc_event_or _expr

to be passed as arguments to the functions wait and


next _tr igger, for exampl e, wait (ev1 & ev2). The obj ects of type sc_event_and_expr

and
sc_event_or _expr

aretemporaries returned by oper ator & or oper ator | in an event expressi on, and would
bedestroyed automati call y after thecal l to wait or next _tr igger . Theimpl ementation shal l deletetheevent
li st object when the process instanceresumes or i s tri ggered as adi rect result of the notification of one or
more events in the event expression. In other words, the impl ementation shal l be responsible for the
creati on, deleti on, and memory management of event li st objects returned fromthe above type conversion
operators.
5.9.4 Operators
oper ator const sc_event _and_l ist & () const;
oper ator const sc_event _or _li st & () const;
Each of thesetypeconversion operators shall return areferenceto an event l ist object equivalent to
the event l ist expressi on represented by the current obj ect * thi s, equivalent i n the sense that the
event l ist object shal l contai n references to thesameset of eventsastheevent l ist expression.
sc_event_and_expr

oper ator & ( sc_event_and_expr

, sc_event const& );
sc_event_and_expr

oper ator & ( sc_event_and_expr

, sc_event_and_l ist const& );


sc_event_or _expr

oper ator | ( sc_event_or _expr

, sc_event const& );
sc_event_or _expr

oper ator | ( sc_event_or _expr

, sc_event_or_l ist const& );


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


97
Copyright 2012 IEEE. All rights reserved.
A cal l to ei ther operator shal l append the event or events passed as the second argument to the event
expression passed as the fi rst argument, and shall return the resul tant elongated event expression as
the val ue of the operator.
Exampl e:
sc_event event1, event2;
void thread_process()
{
...
wait( event1 | event2 );
// When the thread process resumes fol lowi ng the noti fi cation of event1 or event2,
// the impl ementation shall del ete the object of type sc_event_or_expr returned from operator|
...
}
5.10 sc_event
5.10.1 Description
An event is an obj ect of class sc_event used f or process synchronizati on. A process instance may be
triggered or resumed on the occur rence of an event, that i s, when the event is notif ied. Any given event may
be noti fi ed on many separate occasions.
Events can be hi er ar chi cal l y named or not. An event wi thout a hi erarchical name shal l have an
impl ementation-def ined name. A hierarchi cal ly named event shall either have a parent in the object
hierarchy (in which case the event woul d be returned f rom member f unction get_child_events of that
parent) or be a top-level event (in which case the event woul d be returned by f unction
sc_get_top_level_events). I f an event has a parent, that parent shall be ei ther a module instance or a process
instance. An event wi thout a hi erarchical name shal l not have a parent i n the object hierarchy.
A ker nel event i s an event that is instantiated by the impl ementati on, such as an event wi thi n a predefi ned
pri mi tive channel. A kernel event shall not be hierarchi call y named but shal l have an impl ementation-
def ined name, regardless of whether i t i s i nstantiated duri ng elaborati on or duri ng simul ation.
Wi th the exception of kernel events, every event that i s instantiated duri ng el aboration or bef ore the
ini ti al izati on phase shall be a hi erarchical ly named event.
NOTE 1Events without a hierarchical name are provided for backward compatibi l i ty wi th earl i er versi ons of thi s
standard and to avoi d the potential performance i mpact of creati ng hi erachi cal names duri ng si mul ati on.
NOTE 2Although an event may have a parent of type sc_object, an event obj ect i s not i tsel f an sc_object, and hence
an event cannot be returned by member f unction get_child_objects. Member f uncti on get_child_eventsi s provi ded f or
the purpose of retrievi ng the events wi thi n a gi ven modul e or process i nstance.
NOTE 3In the case of a hierarchically named event, the rules f or hi erachi cal nami ng impl y that the name of the event
i s f ormed by concatenati ng the hi erarchi cal name of the parent of the event wi th the basename of the event, wi th the two
parts separated by a peri od character.
5.10.2 Class definition
namespace sc_core {
class sc_event
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


98
Copyright 2012 IEEE. All rights reserved.
{
publ ic:
sc_event();
expl icit sc_event( const char* );
~sc_event();
const char* name() const;
const char* basename() const;
bool in_hierarchy() const;
sc_object* get_parent_object() const;
void notify();
void notify( const sc_ti me& );
void notify( double , sc_time_unit );
void cancel();
sc_event_and_expr

operator& ( const sc_event& ) const;


sc_event_and_expr

operator& ( const sc_event_and_li st& ) const;


sc_event_or _expr

operator| ( const sc_event& ) const;


sc_event_or _expr

operator| ( const sc_event_or_li st& ) const;


pri vate:
// Di sabl ed
sc_event( const sc_event& );
sc_event& operator= ( const sc_event& );
} ;
const std::vector<sc_event* >& sc_get_top_level_events();
sc_event* sc_find_event( const char* );
} // namespace sc_core
5.10.3 Constraints on usage
Objects of cl ass sc_event may be constructed during elaborati on or simul ation. Events may be notif ied
during elaboration or simulati on, except that i t shal l be an error to create an i mmedi ate notif ication duri ng
elaborati on or from one of the cal lbacks before_end_of_elaboration, end_of_elaboration, or
start_of_simulation.
5.10.4 Constructors, destructor, and event naming
sc_event();
expl icit sc_event( const char* );
Call ing the constructor sc_event(const char*) with an empty string shall have the same ef fect as
cal li ng the default constructor, regardl ess of when it is cal led by the appli cation.
When call ed by the applicati on during elaboration or bef ore the initiali zation phase, each of the
above two constructors shall create a hierarchi cal ly named event.
When the def aul t constructor i s call ed by the applicati on f rom the i ni ti al izati on phase onwards,
whether or not a hi erarchically named event i s created shall be implementation-defi ned on a per-
instance basi s.
When the constructor sc_event(const char*) i s call ed by the appli cati on from the i ni ti al izati on
phase onward wi th a non-empty stri ng argument, the impl ementation shall create a hierachicall y
named event.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


99
Copyright 2012 IEEE. All rights reserved.
When a hi erarchical ly named event is constructed, if a non-empty string is passed as a constructor
argument, that string shall be used to set the string name of the event. Otherwi se, the stri ng name
shal l be set to "event". The string name shal l be used to determi ne the hierarchi cal name as
described in 5.17.
I f a constructor needs to substitute a new string name in place of the ori gi nal stri ng name as the
result of a name cl ash, the constructor shal l generate a single warning.
An event that is not hi erarchi cal ly named shall have a non-empty i mplementati on-def ined name.
That name shall take the form of a hi erachi cal name as descri bed in 5.17 but may contain one or
more characters that are not i n the recommended character set f or appl ication-def ined hi erarchical
names (such as punctuati on characters and mathemati cal symbol s). The i ntent is that an
impl ementation may use speci al characters to disti ngui sh impl ementation-defi ned names f rom
appl icati on-def ined names, although it i s not obli ged to do so.
Kernel events shall obey the same rul es as appl icati on-def ined events that are not hierarchi call y
named.
NOTEAn implementation is not required to guarantee that each i mpl ementation-def i ned event name i s
uni que. The i ntent i s that the i mplementati on wi l l use characters not recommended i n appl i cati on-def i ned
names to reduce the probabi l i ty of a name clash between a hi erarchi cal name and an i mpl ementati on-def i ned
name.
~sc_event();
The destructor shall del ete the obj ect and shall remove the event f rom the object hi erarchy such that
the event i s no longer a top-level event or a chi ld event.
5.10.5 Functions for naming and hierarchy traversal
const char* name() const;
Member functi on name shall return the hierarchical name of the event i nstance in the case of a
hierarchi cal ly named event, or otherwi se, i t shall return the impl ementation-defi ned name of the
event i nstance. The name shall al ways be non-empty.
const char* basename() const;
Member f unction basename shal l return the string name of the event instance in the case of a
hierarchi cal ly named event, or otherwise, it shal l return an impl ementation-def ined name. Thi s i s the
string name created when the event instance was constructed. In the case of an i mplementati on-
def ined name, the relati onship between the stri ngs returned from member functions name and
basenameis also implementati on-defi ned.
bool in_hierarchy() const;
Member f unction in_hierarchyshall return the val ue trueif and onl y i f the event is a hierarchi cal ly
named event.
The three f unctions below return information that supports the traversal of events that have a parent in the
object hi erarchy. An i mplementation shal l al low each of these three functi ons to be call ed at any stage
during elaborati on or simul ation. If cal led bef ore elaboration i s complete, they shal l return i nf ormation
concerning the parti al ly constructed object hierarchy as i t exi sts at the time the functions are call ed. I n other
words, a f unction shal l return pointers to any sc_event obj ects that have been constructed before the time the
f uncti on i s cal led but wil l excl ude any objects constructed af ter the f unction i s call ed.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


100
Copyright 2012 IEEE. All rights reserved.
sc_object* get_parent_object() const;
Member function get_parent_object shal l return a pointer to the sc_object that i s the parent of the
current sc_event object in the case of hierarchi cal ly named events, or otherwi se, it shall return the
null pointer. get_parent_object shall also return a null pointer for a top-level event. I f the parent
object is a process i nstance and that process has terminated, get_parent_object shall return a
pointer to that process instance. A process instance shal l not be deleted (nor any associated process
handl es inval idated) whil e the process has surviving chi ldren, but i t may be del eted once all i ts chi ld
objects have been deleted.
const std::vector<sc_event* >& sc_get_top_level_events();
Function sc_get_top_level_events shall return a std::vector contai ni ng pointers to all of the top-
level sc_event objects, that i s, events that are hi erarchicall y named but have no parent.
sc_event* sc_find_event( const char* );
Function sc_find_event shal l return a poi nter to the hierarchi cal ly named sc_event object that has a
name that exactl y matches the value of the string argument or shall return the nul l pointer if there is
no hi erarchicall y named sc_event wi th that name. Functi on sc_find_event shal l not return a poi nter
to an event that has an i mplementati on-def ined name.
5.10.6 notify and cancel
void notify();
A cal l to member functi on notify with an empty argument li st shall create an immediate notif icati on.
Any and all process i nstances sensi tive to the event shall be made runnabl e bef ore control i s returned
from functi on notify, with the exception of the currentl y executing process instance, which shall not
be made runnabl e due to an immedi ate notif icati on regardless of its stati c or dynamic sensi ti vi ty (see
4.2.1.2).
NOTE 1Process instances sensi ti ve to the event wi l l not be resumed or tri ggered unti l the process that cal l ed
notifyhas suspended or returned.
NOTE 2All process instances sensitive to the event wi l l be run i n the current eval uati on phase and i n an order
that i s i mpl ementati on-def i ned. The presence of i mmedi ate noti f i cati on can i ntroduce non-determi ni sti c
behavi or.
NOTE 3Member function update of class sc_prim_channel shal l not cal l notify to create an i mmedi ate
notif i cati on.
void notify( const sc_ti me& );
void notify( double , sc_time_unit );
A call to member f unction notify wi th an argument that represents a zero time shall create a delta
noti ficati on.
A cal l to f uncti on notify with an argument that represents a non-zero ti me shall create a ti med
noti ficati on at the given time, expressed rel ati ve to the simul ation ti me when function notify is
cal led. In other words, the val ue of the ti me argument is added to the current si mulati on time to
determi ne the time at which the event wi ll be notif ied. The ti me argument shall not be negati ve.
NOTEIn the case of a delta notification, all processes that are sensitive to the event in the delta notification
phase wi l l be made runnabl e i n the subsequent eval uati on phase. I n the case of a ti med noti f i cation, al l
processes sensi ti ve to the event at the ti me the event occurs wi ll be made runnabl e at the ti me, which wi ll be a
f uture si mul ati on ti me.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


101
Copyright 2012 IEEE. All rights reserved.
void cancel();
Member f uncti on cancel shall del ete any pending notif ication for thi s event.
NOTE 1At most one pending notification can exist for any gi ven event.
NOTE 2Immediate notificati on cannot be cancel l ed.
5.10.7 Event lists
sc_event_and_expr

operator& ( const sc_event& ) const;


sc_event_and_expr

operator& ( const sc_event_and_li st& ) const;


sc_event_or _expr

operator| ( const sc_event& ) const;


sc_event_or _expr

operator| ( const sc_event_or_l ist& ) const;


A call to ei ther operator shall return an event expression formed by appending the current event
object to the event or event li st passed as an argument.
NOTEEvent lists are used as arguments to functions wait (see 5.2.18) and next_trigger (see 5.2.17).
5.10.8 Multiple event notifications
A given event shall have no more than one pendi ng noti fi cati on.
If f uncti on notify i s call ed f or an event that already has a notif icati on pending, onl y the notif icati on
schedul ed to occur at the earli est time shal l survi ve. The noti fi cati on scheduled to occur at the l ater ti me
shal l be cancel led (or never be scheduled i n the fi rst pl ace). An i mmedi ate notif icati on i s taken to occur
earli er than a delta notif ication, and a del ta noti fi cati on earlier than a ti med notif icati on. Thi s i s irrespecti ve
of the order i n whi ch f uncti on notify is cal led.
Exampl e:
sc_event e;
e.notif y(SC_ZERO_TIME); // Delta noti fi cation
e.notif y(1, SC_NS); // Timed notif icati on i gnored due to pendi ng delta noti fi cation
e.notif y(); // I mmediate notif ication cancel s pendi ng delta notifi cation. e i s noti fi ed
e.notif y(2, SC_NS); // Timed notif i cati on
e.notif y(3, SC_NS); // Timed notif icati on i gnored due to earli er pendi ng timed notif ication
e.notif y(1, SC_NS); // Timed notif icati on cancels pending ti med noti fi cation
e.notif y(SC_ZERO_TIME); // Delta noti fication cancel s pendi ng timed notif icati on
// e i s noti fi ed i n the next del ta cycle
5.11 sc_time
5.11.1 Description
Cl ass sc_time i s used to represent simul ation time and time interval s, including delays and time-outs. An
object of cl ass sc_time is constructed f rom a double and an sc_time_unit. Ti me shall be represented
internal ly as an unsigned integer of at l east 64 bi ts. For i mplementati ons using more than 64 bi ts, the return
val ue of member function valueneed not be of type sc_dt::uint64 (see member f unction valuein 5.11.2).
5.11.2 Class definition
namespace sc_core {
enum sc_time_unit { SC_FS = 0, SC_PS, SC_NS, SC_US, SC_MS, SC_SEC} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


102
Copyright 2012 IEEE. All rights reserved.
class sc_time
{
publ ic:
sc_time();
sc_time( double , sc_ti me_unit );
sc_time( const sc_ti me& );
sc_time& operator= ( const sc_ti me& );
sc_dt::uint64 value() const;
doubl e to_double() const;
doubl e to_seconds() const;
const std::string to_string() const;
bool operator== ( const sc_ti me& ) const;
bool operator!= ( const sc_ti me& ) const;
bool operator< ( const sc_ti me& ) const;
bool operator<= ( const sc_ti me& ) const;
bool operator> ( const sc_ti me& ) const;
bool operator>= ( const sc_ti me& ) const;
sc_time& operator+= ( const sc_ti me& );
sc_time& operator-= ( const sc_ti me& );
sc_time& operator*= ( double );
sc_time& operator/= ( double );
void print( std::ostream& = std::cout ) const;
} ;
const sc_time operator+ ( const sc_time& , const sc_ti me& );
const sc_time operator- ( const sc_ti me& , const sc_ti me& );
const sc_time operator* ( const sc_ti me&, double );
const sc_time operator* ( double, const sc_ti me& );
const sc_time operator/ ( const sc_ti me& , double );
doubl e operator/ ( const sc_ti me& , const sc_ti me& );
std::ostream& operator<< ( std::ostream&, const sc_time& );
const sc_time SC_ZERO_TIME;
void sc_set_time_resolution( double, sc_time_unit );
sc_time sc_get_time_resolution();
const sc_time& sc_max_time();
} // namespace sc_core
5.11.3 Time resolution
Time shal l be represented i nternall y as an i nteger mul tipl e of the time resol uti on. The def aul t ti me resolution
is 1 picosecond. Every object of class sc_timeshal l share a si ngl e common global ti me resol ution.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


103
Copyright 2012 IEEE. All rights reserved.
The ti me resol ution can only be changed by cal ling the f uncti on sc_set_time_resolution. Thi s functi on shall
only be cal led during el aboration, shall not be cal led more than once, and shal l not be call ed after
constructing an object of type sc_time with a non-zero time value. The value of the doubleargument shal l
be positive and shal l be a power of 10. I t shall be an error f or an appli cation to break the rul es gi ven i n thi s
paragraph.
The constructor f or sc_time shal l scale and round the gi ven time val ue to the nearest multiple of the ti me
resoluti on. Whether the value is rounded up or down is i mplementati on-def ined. The def aul t constructor
shal l create an obj ect having a time val ue of zero.
The val ues of enum sc_time_unit shal l be taken to have thei r standard physical meanings, for example,
SC_FS = f emtosecond = 10E-15 seconds.
The f unction sc_get_time_resolution shall return the time resoluti on.
5.11.4 Function sc_max_time
The i mplementati on shall provi de a function sc_max_timewi th the foll owing declaration:
const sc_time& sc_max_time();
The f unction sc_max_time shal l return the maxi mum val ue of type sc_time, cal cul ated af ter taki ng into
account the time resoluti on. Si nce f unction sc_max_timenecessari ly returns a reference to an object of type
sc_time that represents a non-zero time value, the time resolution cannot be modif ied after a cal l to
sc_max_time. Every call to sc_max_time duri ng a given si mulati on run shal l return an object havi ng the
same value and representi ng the maximum si mulati on ti me. The actual val ue is impl ementation-defi ned.
Whether each cal l to sc_max_time returns a reference to the same obj ect or a dif f erent obj ect i s
impl ementation-defi ned.
5.11.5 Functions and operators
Al l arithmetic, relational , equal ity, and assignment operators declared in 5.11.2 shal l be taken to have their
natural meanings when perf ormi ng i nteger arithmetic on the underlying representation of ti me. The resul ts
of i nteger underfl ow and divi de-by-zero shall be impl ementation-defi ned.
sc_dt::uint64 value() const;
doubl e to_double() const;
doubl e to_seconds() const;
These f unctions shal l return the underl yi ng representati on of the time val ue, fi rst converting the
val ue to a double in each of the two cases to_double and to_seconds, and then also scaling the
resultant value to units of 1 second in the case of to_seconds.
const std::string to_string() const;
void print( std::ostream& = std::cout ) const;
std::ostream& operator<< ( std::ostream& , const sc_time& );
These functi ons shal l return the ti me val ue converted to a stri ng or pri nt that string to the gi ven
stream. The f ormat of the stri ng is impl ementation-defi ned.
5.11.6 SC_ZERO_TIME
Constant SC_ZERO_TI ME represents a time value of zero. It i s good practice to use this constant whenever
writi ng a time val ue of zero, for example, when creati ng a del ta notif icati on or a del ta ti me-out.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


104
Copyright 2012 IEEE. All rights reserved.
Exampl e:
sc_event e;
e.notif y(SC_ZERO_TIME); // Delta noti fi cation
wait(SC_ZERO_TIME); // Delta ti me-out
5.12 sc_port
5.12.1 Description
Ports provide the means by whi ch a module can be written such that i t is i ndependent of the context i n which
it i s i nstantiated. A port forwards interface method call s to the channel to which the port is bound. A port
def ines a set of services (as identi fi ed by the type of the port) that are required by the module contai ni ng the
port.
I f a module i s to cal l a member functi on belonging to a channel that i s outsi de the modul e itself , that cal l
should be made usi ng an interface method cal l through a port of the module. To do otherwise is considered
bad coding style. However, a cal l to a member function belonging to a channel instanti ated wi thi n the
current module may be made di rectl y. This is known as portl ess channel access. If a module is to cal l a
member function bel onging to a channel i nstance wi thin a chi ld modul e, that cal l should be made through an
export of the chi ld module (see 5.13).
5.12.2 Class definition
namespace sc_core {
enum sc_port_policy
{
SC_ONE_OR_MORE_BOUND , // Def aul t
SC_ZERO_OR_MORE_BOUND ,
SC_ALL_BOUND
} ;
class sc_port_base
: publi c sc_object { i mpl ementati on-defi ned } ;
templ ate <cl ass I F>
class sc_port_b
: publi c sc_port_base
{
publ ic:
void operator() ( I F& );
void operator() ( sc_port_b<IF>& );
virtual void bind( IF& );
virtual void bind( sc_port_b<IF>& );
int size() const;
IF* operator->();
const I F* operator-> () const;
IF* operator[] ( i nt );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


105
Copyright 2012 IEEE. All rights reserved.
const I F* operator[] ( i nt ) const;
virtual sc_i nterf ace* get_interface();
virtual const sc_i nterf ace* get_interface() const;
protected:
virtual void before_end_of_elaboration();
virtual void end_of_elaboration();
virtual void start_of_simulation();
virtual void end_of_simulation();
expl icit sc_port_b( i nt , sc_port_poli cy );
sc_port_b( const char* , int , sc_port_pol icy );
virtual ~sc_port_b();
pri vate:
// Di sabl ed
sc_port_b();
sc_port_b( const sc_port_b<I F>& );
sc_port_b<I F>& operator = ( const sc_port_b<IF>& );
} ;
templ ate <class I F, i nt N = 1, sc_port_poli cy P = SC_ONE_OR_MORE_BOUND>
class sc_port
: publi c sc_port_b<IF>
{
publ ic:
sc_port();
expl icit sc_port( const char* );
virtual ~sc_port();
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_port( const sc_port<I F,N,P>& );
sc_port<I F,N,P>& operator= ( const sc_port<I F,N,P>& );
} ;
} // namespace sc_core
5.12.3 Template parameters
The fi rst argument to templ ate sc_port shal l be the name of an i nter face proper. This i nterf ace i s said to be
the type of the por t. A port can onl y be bound to a channel deri ved f rom the type of the port or to another
port or export with a type deri ved f rom the type of the port.
The second argument to templ ate sc_port is an optional integer val ue. If present, thi s argument shall speci fy
the maxi mum number of channel instances to whi ch any one i nstance of the port bel ongi ng to any specifi c
module i nstance may be bound. If the value of this argument is zero, the port may be bound to an arbi trary
number of channel instances. It shall be an error to bind a port to more channel instances than the number
permi tted by the second template argument.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


106
Copyright 2012 IEEE. All rights reserved.
The default value of the second argument i s 1. I f the value of the second argument i s not 1, the port is said to
be a mul ti port. If a port i s bound to another port, the value of this argument may dif fer between the two
ports.
The third argument to template sc_port is an optional port poli cy of type sc_port_policy. The port poli cy
argument determi nes the rules f or binding multiports and the rules f or unbound ports.
The poli cy SC_ONE_OR_MORE_BOUND means that the port i nstance shal l be bound to one or more
channel instances, the maxi mum number being determined by the value of the second template argument. It
shall be an error f or the port i nstance to remain unbound at the end of el aboration.
The pol icy SC_ZERO_OR_MORE_BOUND means that the port instance shall be bound to zero or more
channel i nstances, the maximum number being determi ned by the value of the second template argument.
The port instance may remain unbound at the end of elaborati on.
The poli cy SC_ALL_BOUND means that the port i nstance shall be bound to exactl y the number of channel
instances gi ven by value of the second templ ate argument, no more and no l ess, provi ded that val ue i s
greater than zero. If the value of the second template argument i s zero, pol icy SC_ALL_BOUND shall have
the same meaning as poli cy SC_ONE_OR_MORE_BOUND. I t shal l be an error for the port i nstance to
remai n unbound at the end of el aboration, or to be bound to fewer channel instances than the number
required by the second template argument.
I t shall be an error to bi nd a given port i nstance to a gi ven channel i nstance more than once, whether di rectl y
or through another port.
The port poli cy shall apply i ndependentl y to each port instance, even when a port i s bound to another port.
For example, if a port on a chi ld modul e wi th a type sc_port<I F> is bound to a port on a parent modul e wi th
a type sc_port<I F,2,SC_ALL_BOUND>, the two port polici es are contradi ctory and one or other wi ll
inevitabl y resul t in an error at the end of el aboration.
The port poli ci es shal l hol d when port bi ndi ng is compl eted by the i mplementati on j ust bef ore the cal lbacks
to f uncti on end_of_elaboration but are not required to hold any earli er. For exampl e, a port of type
sc_port<I F,2,SC_ALL_BOUND> could be bound once i n a modul e constructor and once i n the cal lback
functi on before_end_of_elaboration.
Exampl e:
sc_port<IF> // Bound to exactl y 1 channel i nstance
sc_port<IF,0> // Bound to 1 or more channel i nstances
// with no upper l imit
sc_port<IF,3> // Bound to 1, 2, or 3 channel i nstances
sc_port<IF,0,SC_ZERO_OR_MORE_BOUND> // Bound to 0 or more channel i nstances
// with no upper l imit
sc_port<IF,1,SC_ZERO_OR_MORE_BOUND> // Bound to 0 or 1 channel instances
sc_port<IF,3,SC_ZERO_OR_MORE_BOUND> // Bound to 0, 1, 2, or 3 channel i nstances
sc_port<IF,3,SC_ALL_BOUND> // Bound to exactl y 3 channel i nstances
NOTEA port may be bound indirectly to a channel by bei ng bound to another port or export (see 4.1.3).
5.12.4 Constraints on usage
An impl ementation shall derive cl ass sc_port_basefrom class sc_object.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


107
Copyright 2012 IEEE. All rights reserved.
Ports shal l only be i nstanti ated duri ng elaborati on and only from within a module. It shall be an error to
instanti ateaport other than withi n amodule. It shall bean error toi nstanti ateaport during si mulati on.
The member functi ons size and get_interface can be call ed duri ng elaborati on or si mulati on, whereas
operator->and operator[] should only becalled fromend_of_elaboration or duri ng simul ation.
It i sstrongl y recommended that aport wi thi nagiven modul ebebound at thepoint wherethegi ven module
is i nstantiated, that is, wi thin the constructor from which the module is i nstantiated. Furthermore, i t i s
strongl y recommended that theport bebound to achannel or another port that isitself i nstantiated wi thin the
modulecontaining theinstanceof thegi ven modul eor to an export that isi nstanti ated wi thin achi ld module.
This recommendati on may be viol ated on occasion. For example, it is convenient to bind an otherwise
unbound port fromthebefore_end_of_elaboration cal lback of theport instanceitself.
Theconstraint that aport bei nstanti ated wi thi n a modul e al lowsfor consi derabl eflexibil ity. However, it i s
strongly recommended that aport i nstancebeadatamember of amodul ewherever practical; otherwise, the
syntax necessary for named port bindi ng becomessomewhat arcanein that it requiresmorethan simpl ecl ass
member access usi ngthedot operator.
Supposeaparticular port i s instantiated within moduleC, and modul eCisi tsel f i nstantiated wi thin module
P. It i spermi ssibl efor theport to bebound at somepoint i n thecoderemotefromthepoi nt at which module
C i s i nstantiated, it is permi ssibl e for the port to be bound to a channel (or another port) that i s itself
instanti ated in amodul eother than themoduleP, and i t i spermi ssibl efor theport to bebound to an export
that i s instanti ated somewhere other than in a chil d modul e of module P. However, all such cases would
result i n a breakdown of the normal discipli ne of the modul e hierarchy and are strongly di scouraged in
typical usage.
5.12.5 Constructors
expl icit sc_port_b( i nt , sc_port_poli cy );
sc_port_b( const char* , int , sc_port_pol icy );
virtual ~sc_port_b();
Theconstructor for class sc_port_b shal l passtheval uesof itsargumentsthough to theconstructor
for thebase cl ass sub-obj ect. Thecharacter string argument shall bethestring nameof thei nstance
in the modul ehierarchy, the int argument shal l bethe maximum number of channel i nstances, and
thesc_port_policy argument shall betheport poli cy.
sc_port();
expl icit sc_port( const char* );
Theconstructor for class sc_port shall pass thecharacter string argument (if such argument exists)
through to the constructor bel ongi ng to the base class sc_port_b to set the stri ng name of the
instancein themodul ehi erarchy, and shal l passthetwo templateparametersN and Pasarguments
to theconstructor for cl asssc_port_b.
Thedefaul t constructor shall call function sc_gen_unique_name("port") to generateauniquestri ng name
that i t shal l then pass through to theconstructor for thebasecl asssc_object.
NOTEA port instance need not be given an explicit string namewithin theapplication when it isconstructed.
5.12.6 kind
Member functi on kind shall return thestring "sc_port".
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


108
Copyright 2012 IEEE. All rights reserved.
5.12.7 Named port binding
Ports can be bound ei ther usi ng the functi ons l isted in thi s subclause for named bindi ng or usi ng the
operator() f rom cl ass sc_module f or positional bindi ng. An impl ementation may defer the compl etion of
port bi ndi ng unti l a later time during el aboration because the port to which a port i s bound may not yet i tself
have been bound. Such deferred port bi nding shal l be compl eted by the i mplementati on before the cal lbacks
to f uncti on end_of_elaboration.
void operator() ( I F& );
virtual void bind( IF& );
Each of these two functi ons shall bind the port instance f or which the function is cal led to the
channel i nstance passed as an argument to the f unction. The actual argument can be an export, i n
which case the C++ compil er wi ll call the i mpli ci t conversi on sc_export<IF>::operator IF&. The
impl ementation of operator() shall achieve i ts ef f ect by cal l ing the virtual member f unction bind.
void operator() ( sc_port_b<IF>& );
virtual void bind( sc_port_b<IF>& );
Each of these two f unctions shal l bind the port instance f or which the f unction i s call ed to the port
instance passed as an argument to the f unction. The i mplementati on of operator() shall achi eve its
eff ect by cal li ng the virtual member f uncti on bind.
Exampl e:
SC_MODULE(M)
{
sc_i nout<i nt> P, Q, R, S; // Ports
sc_i nout<i nt> * T; // Poi nter-to-port (not a recommended codi ng styl e)
SC_CTOR(M) { T = new sc_i nout<i nt>; }
...
} ;
SC_MODULE(Top)
{
sc_i nout <i nt> A, B;
sc_signal <int> C, D;
M m; // Module instance
SC_CTOR(Top)
: m("m")
{
m.P(A); // Binds P-to-A
m.Q.bind(B); // Bi nds Q-to-B
m.R(C); // Binds R-to-C
m.S.bind(D); // Bi nds S-to-D
m.T->bind(E); // Bi nds T-to-E
}
...
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


109
Copyright 2012 IEEE. All rights reserved.
5.12.8 Member functions for bound ports and port-to-port binding
The member f uncti ons descri bed in thi s subcl ause return i nformation about ports that have been bound
duri ng el aboration. These functi ons return informati on concerning the ordered set of channel i nstances to
which a particular port instance (whi ch may or may not be a mul ti port) is bound.
The ordered set S of channel instances to whi ch a gi ven port i s bound (f or the purpose of defi ning the
semantics of the f uncti ons given in thi s subclause) is determined as foll ows.
a) When the port or export is bound to a channel i nstance, that channel instance shall be added to the
end of the ordered set S.
b) When the port or export i s bound to an export, rules a) and b) shal l be applied recursivel y to the
export.
c) When the port is bound to another port, rules a), b), and c) shal l be appl ied recursively to the other
port.
Because an i mplementati on may def er the compl etion of port bi ndi ng unti l a later time duri ng elaborati on,
the number and order of the channel instances as returned from the member f unctions descri bed in thi s
subclause may change during el aborati on and the f inal order is impl ementation-defi ned, but i t shal l not
change duri ng the end_of_elaboration cal lback or duri ng simul ation.
NOTEAs a consequence of the above rules, a given channel instance may appear to li e at a dif f erent posi ti on i n the
ordered set of channel i nstances when vi ewed f rom ports at di f ferent posi ti ons i n the modul e hierarchy. For exampl e, a
gi ven channel i nstance may be the f i rst channel i nstance to which a port of a parent modul e i s bound but the thi rd
channel i nstance to whi ch a port of a chi l d modul e i s bound.
5.12.8.1 size
int size() const;
Member f unction sizeshal l return the number of channel instances to which the port i nstance for which it i s
cal led has been bound.
I f member function sizei s cal led during elaborati on and before the call back end_of_elaboration, the value
returned is impl ementation-def ined because the time at which port bi ndi ng is completed is i mplementati on-
def ined.
NOTEThe value returned by sizewi l l be 1 f or a typical port but may be 0 i f the port is unbound or greater than 1 f or a
mul ti port.
5.12.8.2 operator->
IF* operator-> ();
const I F* operator-> () const;
operator-> shal l return a poi nter to the fi rst channel instance to which the port was bound during
elaborati on.
I t shal l be an error to cal l operator-> f or an unbound port. If operator-> i s call ed during elaborati on and
bef ore the call back end_of_elaboration, the behavi or i s impl ementation-def ined because the time at which
port bi ndi ng i s completed is impl ementation-defi ned.
NOTEoperator-> i s key to the i nterf ace method cal l paradi gm i n that i t permi ts a process to cal l a member f uncti on,
def ined i n a channel, through a port bound to that channel .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


110
Copyright 2012 IEEE. All rights reserved.
Exampl e:
struct i face
: vi rtual sc_i nterf ace
{
virtual int read() const = 0;
} ;
struct chan
: i face, sc_prim_channel
{
virtual int read() const;
} ;
int chan::read() const { ... }
SC_MODULE(modu)
{
sc_port<if ace> P;
SC_CTOR(modu)
{
SC_THREAD(thread);
}
void thread()
{
int i = P->read(); // I nterf ace method call
}
} ;
SC_MODULE(top)
{
modu * mo;
chan * ch;
SC_CTOR(top)
{
ch = new chan;
mo = new modu("mo");
mo->P(* ch); // Port Pbound to channel * ch
}
} ;
5.12.8.3 operator[]
IF* operator[] ( i nt );
const I F* operator[] ( i nt ) const;
operator[] shall return a poi nter to a channel i nstance to whi ch a port i s bound. The argument identi fies
which channel i nstance shall be returned. The i nstances are numbered starting f rom zero i n the order in
which the port binding was completed, the order bei ng i mplementati on-def ined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


111
Copyright 2012 IEEE. All rights reserved.
The value of the argument shall li e i n the range 0 to N 1, where N is the number of instances to which the
port is bound. It shall be an error to cal l operator[] wi th an argument val ue that li es outside thi s range. If
operator[] i s call ed duri ng el aboration and before the call back end_of_elaboration, the behavior is
impl ementation-def ined because the time at whi ch port bi ndi ng i s completed is impl ementation-defi ned.
operator[] may be cal led f or a port that i s not a multiport, in whi ch case the val ue of the argument should be
0.
Exampl e:
class bus_interface;
class slave_i nterf ace
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual void sl ave_wri te(int addr, int data) = 0;
virtual void sl ave_read (i nt addr, int& data) = 0;
} ;
class bus_channel
: publi c bus_i nterf ace, publi c sc_modul e
{
publ ic:
...
sc_port<sl ave_interface, 0> slave_port; // Multi port f or attaching sl aves to bus
SC_CTOR(bus_channel)
{
SC_THREAD(acti on);
}
pri vate:
void action()
{
f or (i nt i = 0; i < sl ave_port.size(); i++) // Functi on size() returns number of slaves
slave_port[i ]->sl ave_wri te(0,0); // Operator[ ] i ndexes slave port
}
} ;
class memory
: publi c slave_i nterf ace, publ ic sc_modul e
{
publ ic:
virtual void sl ave_wri te(int addr, int data);
virtual void sl ave_read (int addr, int& data);
...
} ;
SC_MODULE(top_level )
{
bus_channel bus;
memory ram0, ram1, ram2, ram3;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


112
Copyright 2012 IEEE. All rights reserved.
SC_CTOR(top_l evel)
: bus("bus"), ram0("ram0"), ram1("ram1"), ram2("ram2"), ram3("ram3")
{
bus.slave_port(ram0);
bus.slave_port(ram1);
bus.slave_port(ram2);
bus.slave_port(ram3); // One mul tiport bound to four memory channel s
}
} ;
5.12.8.4 get_interface
virtual sc_i nterf ace* get_interface();
virtual const sc_i nterf ace* get_interface() const;
Member functi on get_interfaceshall return a poi nter to the fi rst channel i nstance to which the port is bound.
I f the port i s unbound, a null poi nter shall be returned. This member function may be cal led during
elaboration to test whether a port has yet been bound. Because the ti me at which deferred port binding i s
compl eted i s impl ementation-defi ned, it i s impl ementation-defi ned whether get_interface returns a pointer
to a channel i nstance or a null poi nter when cal led duri ng construction or from the callback
before_end_of_elaboration.
get_interfaceis intended f or use i n i mplementi ng speciali zed port cl asses derived f rom sc_port. In general ,
an appl ication shoul d cal l operator-> i nstead. However, get_interface permi ts an applicati on to call a
member f uncti on of the cl ass of the channel to which the port i s bound, even i f such a function is not a
member of the i nterf ace type of the port.
NOTEFunction get_interfacecannot return channel s beyond the f i rst channel i nstance to whi ch a mul ti port is bound;
use operator[] i nstead.
Exampl e:
SC_MODULE(Top)
{
sc_i n<bool> clock;
void bef ore_end_of_el aboration()
{
sc_i nterf ace* i _f = clock.get_i nterf ace();
sc_clock* clk = dynami c_cast<sc_clock* >(i_f );
sc_ti me t = clk->period(); // Cal l method of clock object to whi ch port is bound
...
5.12.9 before_end_of_elaboration, end_of_elaboration, start_of_simulation,
end_of_simulation
See 4.4.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


113
Copyright 2012 IEEE. All rights reserved.
5.13 sc_export
5.13.1 Description
Cl ass sc_export all ows a modul e to provi de an i nterf ace to its parent modul e. An export forwards interf ace
method call s to the channel to which the export i s bound. An export def ines a set of servi ces (as identif ied by
the type of the export) that are provided by the module contai ni ng the export.
Providi ng an interf ace through an export i s an alternative to a modul e si mply i mplementing the interface.
The use of an expli ci t export al lows a single modul e i nstance to provide mul ti ple interfaces in a structured
manner.
If a module i s to cal l a member function bel onging to a channel i nstance wi thi n a chil d module, that call
should be made through an export of the chil d module.
5.13.2 Class definition
namespace sc_core {
class sc_export_base
: publi c sc_object { i mpl ementati on-defi ned } ;
templ ate<cl ass I F>
class sc_export
: publi c sc_export_base
{
publ ic:
sc_export();
expl icit sc_export( const char* );
virtual ~sc_export();
virtual const char* kind() const;
void operator() ( I F& );
virtual void bind( IF& );
operator IF& ();
operator const I F& () const;
IF* operator->();
const I F* operator-> () const;
virtual sc_i nterf ace* get_interface();
virtual const sc_i nterf ace* get_interface() const;
protected:
virtual void before_end_of_elaboration();
virtual void end_of_elaboration();
virtual void start_of_simulation();
virtual void end_of_simulation();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


114
Copyright 2012 IEEE. All rights reserved.
pri vate
// Di sabl ed
sc_export( const sc_export<IF>& );
sc_export<I F>& operator= ( const sc_export<IF>& );
} ;
} // namespace sc_core
5.13.3 Template parameters
The argument to templ ate sc_export shall be the name of an interface proper. This interface i s sai d to be the
type of the expor t. An export can onl y be bound to a channel deri ved f rom the type of the export or to
another export with a type derived f rom the type of the export.
NOTEAn export may be bound indirectly to a channel by bei ng bound to another export (see 4.1.3).
5.13.4 Constraints on usage
An impl ementation shall derive cl ass sc_export_basefrom class sc_object.
Exports shall only be i nstanti ated duri ng elaborati on and only from withi n a modul e. I t shall be an error to
instanti ate an export other than within a modul e. It shal l be an error to i nstanti ate an export duri ng
simul ation.
Every export of every modul e instance shal l be bound once and once only duri ng el aborati on. It shal l be an
error to have an export remai ning unbound at the end of elaborati on. I t shal l be an error to bind an export to
more than one channel .
The member f unction get_interface can be cal led during el aborati on or simul ation, whereas operator->
should only be called during si mulation.
I t is strongly recommended that an export within a given module be bound within that same module.
Furthermore, i t i s strongly recommended that the export be bound to a channel that is i tsel f instantiated
wi thin the current module or implemented by the current module or bound to an export that is i nstantiated
wi thin a child module. Any other usage would result in a breakdown of the normal discipli ne of the module
hierarchy and is strongly discouraged (see 5.12.4).
5.13.5 Constructors
sc_export();
expl icit sc_export( const char* );
The constructor f or class sc_export shall pass the character string argument (i f there i s one) through
to the constructor bel ongi ng to the base class sc_object i n order to set the string name of the i nstance
in the module hi erarchy.
The default constructor shall cal l f uncti on sc_gen_unique_name("export") in order to generate a
unique string name that i t shal l then pass through to the constructor for the base cl ass sc_object.
NOTEAn export instance need not be given an expli ci t stri ng name wi thi n the appl i cati on when i t i s
constructed.
5.13.6 kind
Member f uncti on kind shall return the string "sc_export".
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


115
Copyright 2012 IEEE. All rights reserved.
5.13.7 Export binding
Exports can be bound usi ng ei ther of the two f unctions defi ned here. The noti on of positional bi ndi ng i s not
appl icabl e to exports. Each of these functi ons shal l bi nd the export i mmediately, i n contrast to ports f or
which the impl ementation may need to defer the binding.
void operator() ( I F& );
virtual void bind( IF& );
Each of these two functions shal l bi nd the export instance for which the f uncti on i s call ed to the
channel i nstance passed as an argument to the f uncti on. The i mplementati on of operator() shal l
achi eve its eff ect by cal li ng the virtual member f unction bind.
NOTEThe actual argument could be an export, in which case operator I F& woul d be cal l ed as an i mpli ci t
conversi on.
Exampl e:
struct i_f: vi rtual sc_interface
{
virtual void pri nt() = 0;
} ;
struct Chan: sc_channel, i_f
{
SC_CTOR(Chan) { }
void pri nt() { std::cout << "I'm Chan, name=" << name() << std::endl; }
} ;
struct Cal ler: sc_modul e
{
sc_port<i_f> p;
...
} ;
struct Bottom: sc_modul e
{
sc_export<i _f > xp;
Chan ch;
SC_CTOR(Bottom) : ch("ch")
{
xp.bi nd(ch); // Bind export xp to channel ch
}
} ;
struct Middle: sc_modul e
{
sc_export<i _f > xp;
Bottom* b;
SC_CTOR(Middle)
{
b = new Bottom ("b");
xp.bi nd(b->xp); // Bi nd export xp to export b->xp
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


116
Copyright 2012 IEEE. All rights reserved.
b->xp->print(); // Call method of export withi n chil d modul e
}
} ;
struct Top: sc_modul e
{
Call er* c;
Mi ddl e* m;
SC_CTOR(Top)
{
c = new Call er ("c");
m = new Middle ("m");
c->p(m->xp); // Bi nd port c->p to export m->xp
}
} ;
5.13.8 Member functions for bound exports and export-to-export binding
The member functi ons described in this subcl ause return i nformation about exports that have been bound
duri ng el aboration, and hence, these member functions shoul d only be call ed af ter the export has been bound
duri ng elaboration or simulation. These functi ons return i nf ormation concerning the channel i nstance to
which a particular export instance has been bound.
I t shall be an error to bi nd an export more than once. I t shall be an error f or an export to be unbound at the
end of elaborati on.
The channel i nstance to whi ch a given export is bound (f or the purpose of def ini ng the semantics of the
f uncti ons given i n this subcl ause) i s determi ned as f oll ows:
a) I f the export is bound to a channel i nstance, that i s the channel instance i n question.
b) I f the export i s bound to another export, rules a) and b) shal l be appl ied recursively to the other
export.
5.13.8.1 operator-> and operator IF&
IF* operator-> ();
const I F* operator-> () const;
operator IF& ();
operator const I F& () const;
operator-> and operator I F& shall both return a pointer to the channel instance to whi ch the export
was bound duri ng el aborati on.
I t shall be an error for an appl ication to cal l thi s operator i f the export i s unbound.
NOTE 1operator-> i s i ntended f or use duri ng si mul ati on when maki ng an i nterf ace method cal l through an
export i nstance f rom a parent modul e of the modul e contai ni ng the export.
NOTE 2operator I F& is i ntended f or use duri ng el aborati on as an impl i ci t conversi on when passi ng an
object of class sc_export i n a context that requi res an sc_interface, f or exampl e, when bi ndi ng a port to an
export or when addi ng an export to the stati c sensi ti vi ty of a process.
NOTE 3There is no operator[] f or cl ass sc_export, and there i s no noti on of a mul ti -export. Each export can
onl y be bound to a si ngl e channel .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


117
Copyright 2012 IEEE. All rights reserved.
5.13.8.2 get_interface
virtual sc_i nterf ace* get_interface();
virtual const sc_i nterf ace* get_interface() const;
Member functi on get_interfaceshal l return a pointer to the channel i nstance to whi ch the export is
bound. I f the export is unbound, a null pointer shall be returned. Thi s member function may be
cal led during el aboration to test whether an export has yet been bound.
5.13.9 before_end_of_elaboration, end_of_elaboration, start_of_simulation,
end_of_simulation
See 4.4.
5.14 sc_interface
5.14.1 Description
sc_interfaceis the abstract base class f or al l i nterf aces.
An i nter face is a class derived f rom the class sc_interface. An i nter face pr oper is an abstract cl ass deri ved
f rom class sc_interface but not deri ved f rom class sc_object. An interface proper contains a set of pure
virtual functions that shal l be def ined in one or more channels deri ved f rom that interface proper. Such a
channel is said to i mpl ement the interface.
NOTE 1The term i nter face pr oper i s used to di sti ngui sh an i nterf ace proper f rom a channel. A channel is a cl ass
deri ved i ndi rectl y f rom cl ass sc_interface, and i n that sense, a channel i s an i nterf ace. However, a channel i s not an
i nterf ace proper.
NOTE 2As a consequence of the rules of C++, an i nstance of a channel deri ved f rom an i nterf ace I F or a poi nter to
such an i nstance can be passed as the argument to a functi on wi th a parameter of type I F& or I F*, respecti vel y, or a port
of type I F can be bound to such a channel .
5.14.2 Class definition
namespace sc_core {
class sc_interface
{
publ ic:
virtual void register_port( sc_port_base& , const char* );
virtual const sc_event& default_event() const;
virtual ~sc_interface();
protected:
sc_interface();
pri vate:
// Di sabl ed
sc_interface( const sc_interface& );
sc_i nterf ace& operator= ( const sc_interface& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


118
Copyright 2012 IEEE. All rights reserved.
5.14.3 Constraints on usage
An appli cation shoul d not use class sc_interfaceas the di rect base cl ass f or any class other than an interface
proper.
An interface proper shal l obey the f ol lowi ng rul es:
a) I t shall be publi cl y deri ved directly or indirectly f rom class sc_interface.
b) I f directly derived f rom cl ass sc_interface, it shall use the virtual specif ier.
c) I t shall not be deri ved directl y or indirectly from cl ass sc_object.
An interface proper shoul d typi cal ly obey the foll owing rules:
a) I t should contain one or more pure virtual functi ons.
b) It should not be derived f rom any other cl ass that is not itself an i nterf ace proper.
c) I t should not contai n any function decl arations or function def ini ti ons apart from the pure virtual
f uncti ons.
d) I t should not contai n any data members.
NOTE 1An interface proper may be derived from another i nterf ace proper or f rom two or more other i nterf aces
proper, thus creati ng a multi pl e i nheri tance hi erarchy.
NOTE 2A channel class may be deri ved f rom any number of i nterfaces proper.
5.14.4 register_port
virtual void register_port( sc_port_base& , const char* );
The defi ni ti on of this function in class sc_interfacedoes nothi ng. An appli cation may overri de this f unction
in a channel .
The purpose of functi on register_port is to enable an appli cation to perf orm actions that depend on port
binding during elaboration, such as checking connectivi ty errors.
Member functi on register_port of a channel shal l be call ed by the impl ementation whenever a port is bound
to a channel i nstance. The f irst argument shal l be a ref erence to the port instance being bound. The second
argument shall be the value returned from the expression typeid( I F ).name(), where I F is the i nterf ace type
of the port.
Member f uncti on register_port shall not be cal led when an export i s bound to a channel .
I f a port P i s bound to another port Q, and port Q is in turn bound to a channel instance, the f irst argument to
member function register_port shall be the port P. I n other words, register_port i s not passed a ref erence to
a port on a parent modul e if a port on a chil d module is i n turn bound to that port; i nstead, i t is passed as a
ref erence to the port on the chi ld module, and so on recursi vel y down the modul e hi erarchy.
I n the case that multipl e ports are bound to the same si ngle channel i nstance or port instance, member
functi on register_port shal l be call ed once for each port so bound.
Exampl e:
void register_port( sc_port_base& port_, const char* if _typename_ )
{
std::stri ng nm( if _typename_ );
if ( nm == typeid( my_i nterf ace ).name() )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


119
Copyright 2012 IEEE. All rights reserved.
std::cout << " channel " << name() << " bound to port " << port_.name() << std::endl;
}
5.14.5 default_event
virtual const sc_event& default_event() const;
Member f uncti on default_event shall be call ed by the implementation in every case where a port or channel
instance i s used to def ine the static sensitivi ty of a process instance by bei ng passed directly as an argument
to operator<< of class sc_sensi ti ve

. I n such a case, the appl ication shall override thi s f unction in the
channel in questi on to return a reference to an event to whi ch the process instance wil l be made sensi ti ve.
I f this f uncti on is call ed by the i mpl ementation but not overri dden by the appli cation, the i mplementati on
may generate a warning.
Exampl e:
struct my_i f
: vi rtual sc_i nterf ace
{
virtual i nt read() = 0;
} ;
class my_ch
: publi c my_i f, publ ic sc_modul e
{
publ ic:
virtual int read() { return m_val; }
virtual const sc_event& def ault_event() const { return m_ev; }
pri vate:
int m_val ;
sc_event m_ev;
...
} ;
5.15 sc_prim_channel
5.15.1 Description
sc_prim_channel is the base cl ass f or all primitive channels and provides such channels with uni que access
to the update phase of the scheduler. In common with hi erarchical channel s, a pri mitive channel may
provide publ ic member f uncti ons that can be cal led usi ng the i nterf ace method call paradi gm.
This standard provi des a number of predef ined pri mitive channels to model common communication
mechanisms (see Cl ause 6).
5.15.2 Class definition
namespace sc_core {
class sc_prim_channel
: publi c sc_object
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


120
Copyright 2012 IEEE. All rights reserved.
publ ic:
virtual const char* kind() const;
protected:
sc_prim_channel();
expl icit sc_prim_channel( const char* );
virtual ~sc_prim_channel();
void request_update();
void async_request_update();
virtual void update();
void next_trigger();
void next_trigger( const sc_event& );
void next_trigger( const sc_event_or_li st & );
void next_trigger( const sc_event_and_li st & );
void next_trigger( const sc_ti me& );
void next_trigger( double , sc_ti me_unit );
void next_trigger( const sc_ti me& , const sc_event& );
void next_trigger( double , sc_ti me_unit , const sc_event& );
void next_trigger( const sc_ti me& , const sc_event_or_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_or_li st & );
void next_trigger( const sc_ti me& , const sc_event_and_li st & );
void next_trigger( double , sc_ti me_unit , const sc_event_and_li st & );
void wait();
void wait( i nt );
void wait( const sc_event& );
void wait( const sc_event_or_l ist & );
void wait( const sc_event_and_l ist & );
void wait( const sc_ti me& );
void wait( double , sc_time_unit );
void wait( const sc_ti me& , const sc_event& );
void wait( double , sc_time_unit , const sc_event& );
void wait( const sc_ti me& , const sc_event_or_l ist & );
void wait( double , sc_time_unit , const sc_event_or_l ist & );
void wait( const sc_ti me& , const sc_event_and_l ist & );
void wait( double , sc_time_unit , const sc_event_and_li st & );
virtual void before_end_of_elaboration();
virtual void end_of_elaboration();
virtual void start_of_simulation();
virtual void end_of_simulation();
pri vate:
// Di sabl ed
sc_prim_channel( const sc_prim_channel& );
sc_pri m_channel & operator= ( const sc_prim_channel& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


121
Copyright 2012 IEEE. All rights reserved.
5.15.3 Constraints on usage
Objects of class sc_prim_channel can only be constructed duri ng el aborati on. I t shall be an error to
instanti ate a pri mitive channel during si mulati on.
A pri mi tive channel should be publ i cl y derived from cl ass sc_prim_channel.
A pri mi tive channel shall i mplement one or more i nterf aces.
Member f uncti ons request_update and async_request_update may be cal led during elaborati on or
simul ation. If call ed duri ng elaborati on, the update request shal l be executed duri ng the i ni ti al izati on phase.
NOTEBecause the constructors are protected, cl ass sc_prim_channel cannot be i nstanti ated di rectl y but may be used
as a base cl ass for a pri miti ve channel .
5.15.4 Constructors, destructor, and hierarchical names
sc_prim_channel();
expl icit sc_prim_channel( const char* );
The constructor for class sc_prim_channel shall pass the character stri ng argument (i f such argument
exi sts) through to the constructor belonging to the base class sc_object to set the string name of the instance
in the module hierarchy.
NOTEA class derived from class sc_prim_channel i s not obl i ged to have a constructor, in whi ch case the def ault
constructor f or cl ass sc_object wi l l generate a uni que stri ng name. As a consequence, a pri mi ti ve channel i nstance need
not be gi ven an expl i ci t stri ng name wi thi n the appl i cati on when it i s constructed.
5.15.5 kind
Member f uncti on kind shall return the string "sc_prim_channel".
5.15.6 request_update and update
Member functions request_updateand async_request_updateeach cause the schedul er to queue an update
request. An appli cation shoul d not cal l both request_update and async_request_update for a gi ven
pri mitive channel i nstance at any ti me duri ng el aboration or si mulati on, but it may do so f or di ff erent
pri mitive channel i nstances. If both request_update and async_request_update are cal led for the same
pri mitive channel instance, the behavi or of the impl ementation is undefi ned.
void request_update();
Member function request_update shal l cause the scheduler to queue an update request f or the
current primi ti ve channel (see 4.2.1.3). No more than one update request shall be queued f or any
given primi ti ve channel i nstance i n any given update phase; that is, mul ti ple call s to
request_updatein the same eval uation phase shal l result i n a single update request.
void async_request_update();
Member function async_request_update shal l cause the scheduler to queue an update request f or
the current primitive channel in a thread-safe manner with respect to the host operating system. The
intent of async_request_update i s that it may be call ed rel iably f rom an operating system thread
other than those in whi ch the SystemC kernel and any SystemC thread processes are executing.
An appli cati on may cal l async_request_update at any time during elaborati on or simul ati on, and
these call s may be asynchronous wi th respect to the SystemC kernel . The impl ementation shall
guarantee that each call to async_request_updatebehaves as i f i t were executed in an eval uation
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


122
Copyright 2012 IEEE. All rights reserved.
phase. No morethanoneupdaterequest shall bequeued for any given primitivechannel instancein
any given update phase; that is, multiple cal ls to async_request_update recei ved by the kernel
between two consecuti veupdatephases shall result in asi ngl eupdaterequest. Thepreci sephasei n
which any gi ven cal l to async_request_update i s received and processed by the kernel i s
undefined. As a consequence, two cal ls to async_request_update for the same primiti ve channel
and occurring wi thin a narrow time window may resul t in a si ngl e update request, two update
requests in consecutivedeltacycles, or two updaterequestsi nnon-consecutivedel tacycles.
The appli cation i s responsi ble for synchronizing access to any shared memory across cal ls to
async_request_update and update. The software thread that cal ls async_request_update would
typi call y need towriteavalueto somevari abl ethat i sread by function update. Theimpl ementation
can givenoguaranteewi th regard to theintegrity of any such shared memory.
It is not recommended to cal l member function async_request_update fromfunctions executed i n
the context of the SystemC kernel, such as SystemC thread or method processes, but only by
operating system threads separate from the kernel . Cal li ng async_request_update may cause a
performancedegradati oncompared to request_update.
virtual void update();
Member functi on updateshall becal led back by theschedul er duri ng theupdatephasein response
to a cal l to request_update or async_request_update. An appl ication may override this member
functi on i n aprimi ti vechannel. Thedefinition of thi sfunction in cl ass sc_prim_channel itsel f does
nothing.
When overridden in aderi ved class, member function updateshall not performany of thefol lowi ng
actions:
a) Cal l any member functi on of cl ass sc_prim_channel wi th the exception of member function
updateitsel f i f overri dden within abaseclassof thecurrent object
b) Cal l member function notify() of cl ass sc_event wi th no arguments to create an immediate
notificati on
c) Cal l any of the member functi ons of class sc_process_handlefor process control (suspend or
kill, for example)
If the appli cation viol ates the three rul es just given, the behavior of the impl ementation shal l be
undefined.
Member function updateshoul dnot changethestateof any storageexcept for datamembersof the
current object. Doi ng somay resul t i n non-deterministi c behavi or.
Member functi on update should not read thestate of any primi ti vechannel i nstanceother than the
current object. Doi ng somay resul t i n non-deterministi c behavi or.
Member functi on updateshould not cal l interfacemethodsof other channel instances. Inparticular,
member functi on updateshould not writetoany si gnals.
Member function updatemay call functi on sc_spawn to createadynami c process instance. Such a
processshall not becomerunnableuntil thenext eval uati on phase.
NOTE 1The purpose of the member functions request_update and update is to permit simultaneous
requeststoachannel madeduring theevaluationphasetoberesolved or arbitrated during theupdatephase. The
natureof thearbitration is theresponsibility of theapplication; for example, thebehavior of member function
updatemay bedeterministic or random.
NOTE 2update will typically only read and modify data members of the current object and create delta
notifications.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


123
Copyright 2012 IEEE. All rights reserved.
5.15.7 next_trigger and wait
The behavior of the member functi ons wait and next_trigger of cl ass sc_prim_channel shall be i denti cal to
that of the member functions of cl ass sc_modulewith the same function names and si gnatures. Aside f rom
the fact that they are members of di f ferent classes and so have dif ferent scopes, the restri ctions concerni ng
the context in which the member functi ons may be cal led i s also i dentical . For example, the member
functi on next_trigger shall onl y be cal led from a method process.
5.15.8 before_end_of_elaboration, end_of_elaboration, start_of_simulation,
end_of_simulation
See 4.4.
Exampl e:
struct my_i f
: vi rtual sc_interf ace // An i nterf ace proper
{
virtual i nt read() = 0;
virtual void wri te(int) = 0;
} ;
struct my_prim
: sc_prim_channel, my_if // A pri mitive channel
{
my_pri m() // Default constructor
:
sc_pri m_channel ( sc_gen_unique_name("my_pri m") ),
m_req(false),
m_written(f al se),
m_cur_val (0) { }
virtual void wri te(i nt val)
{
if (! m_req) // Only keeps the 1st val ue wri tten in any one delta
{
m_new_val = val;
request_update(); // Schedul es an update request
m_req = true;
}
}
virtual void update() // Called back by the schedul er in the update phase
{
m_cur_val = m_new_val;
m_req = false;
m_written = true;
m_write_event.notify(SC_ZERO_TI ME); // A delta noti fi cation
}
virtual int read()
{
if (! m_wri tten) wai t(m_write_event); // Blocked unti l update() is cal led
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


124
Copyright 2012 IEEE. All rights reserved.
m_written = f alse;
return m_cur_val ;
}
bool m_req, m_wri tten;
sc_event m_wri te_event;
int m_new_val, m_cur_val ;
} ;
5.16 sc_object
5.16.1 Description
Cl ass sc_object i s the common base cl ass f or cl asses sc_module, sc_port, sc_export, and
sc_prim_channel, and f or the i mplementati on-def i ned classes associ ated with spawned and unspawned
process i nstances. The set of sc_objects shall be organized i nto an obj ect hi erar chy, where each sc_object
has no more than one parent but may have multipl e sibli ngs and mul ti pl e chil dren. Onl y modul e objects and
process obj ects can have chi ldren.
An sc_object i s a chi l d of a module i nstance if and only i f that obj ect li es wi thi n the modul e instance, as
def ined in 3.1.4. An sc_object is a chi l d of a process instance i f and onl y if that object was created duri ng
the executi on of the function associ ated wi th that process i nstance. Obj ect P is a parent of object C i f and
only if C is a chil d of P.
An sc_object that has no parent obj ect i s said to be a top-l evel object. Modul e i nstances, spawned process
instances, and obj ects of an appl ication-defi ned cl ass deri ved from cl ass sc_object may be top-l evel obj ects.
Each call to f unction sc_spawnshall create a spawned process i nstance that is either a chi ld of the cal ler or a
top-l evel object. The parent of the spawned process instance so created may be another spawned process
instance, an unspawned process instance, or a module instance. Alternatively, the spawned process instance
may be a top-l evel object.
Each sc_object shal l have a unique hi erarchical name ref lecting its posi ti on i n the object hierarchy.
Except where expl icitly f orbidden (as is the case for the cl asses sc_module, sc_port, sc_export, and
sc_prim_channel), objects of a class derived f rom sc_object may be deleted at any ti me. When such an
sc_object i s deleted, it ceases to be a chi ld. The object associated wi th a process i nstance shall not be del eted
whil e the process has surviving chil dren, but i t may be deleted by the impl ementation once al l its chi ld
objects have been deleted.
Attributes may be added to each sc_object.
NOTEAn implementation may permit multiple top-level sc_objects (see 4.3).
5.16.2 Class definition
namespace sc_core {
class sc_object
{
publ ic:
const char* name() const;
const char* basename() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


125
Copyright 2012 IEEE. All rights reserved.
virtual const char* kind() const;
virtual void print( std::ostream& = std::cout ) const;
virtual void dump( std::ostream& = std::cout ) const;
virtual const std::vector<sc_object* >& get_child_objects() const;
virtual const std::vector<sc_event* >& get_child_events() const;
sc_object* get_parent_object() const;
bool add_attribute( sc_attr_base& );
sc_attr_base* get_attribute( const std::stri ng& );
const sc_attr_base* get_attribute( const std::string& ) const;
sc_attr_base* remove_attribute( const std::string& );
void remove_all_attributes();
int num_attributes() const;
sc_attr_cltn& attr_cltn();
const sc_attr_cltn& attr_cltn() const;
protected:
sc_object();
sc_object(const char* );
sc_object( const sc_obj ect& );
sc_object& operator= ( const sc_obj ect& );
virtual ~sc_object();
} ;
const std::vector<sc_object* >& sc_get_top_level_objects();
sc_object* sc_find_object( const char* );
} // namespace sc_core
5.16.3 Constraints on usage
An appli cation may use class sc_object as a base class f or other classes besi des modul es, ports, exports,
pri mitive channels, and processes. An appli cation may access the hierarchi cal name of such an object or may
add attri butes to such an obj ect.
An appl ication shal l not def ine a class that has two or more base class sub-obj ects of class sc_object.
Objects of class sc_object may be i nstantiated duri ng el aboration or may be instantiated during simul ation.
However, modul es, ports, exports, and primitive channels can only be i nstantiated during el aboration. It is
permi tted to create a channel that is nei ther a hierarchi cal channel nor a primitive channel but i s nonethel ess
derived from cl ass sc_object, and to instantiate such a channel ei ther during el aboration or simul ation.
Portless channel access is permi tted for any channel , but a port or export cannot be bound to a channel that i s
instanti ated duri ng simul ation.
NOTE 1Because the constructors are protected, cl ass sc_object cannot be i nstanti ated di rectl y.
NOTE 2Since the classes having sc_object as a di rect base cl ass (that is, sc_module, sc_port, sc_export, and
sc_prim_channel) have cl ass sc_object as a non-virtual base cl ass, any cl ass deri ved f rom these cl asses can have at
most one direct base cl ass deri ved f rom class sc_object. I n other words, mul ti pl e i nheri tance f rom the cl asses deri ved
f rom cl ass sc_object i s not permi tted.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


126
Copyright 2012 IEEE. All rights reserved.
5.16.4 Constructors and destructor
sc_object();
sc_object(const char* );
Both constructors shal l register the sc_object as part of the obj ect hi erarchy and shall construct a
hierarchi cal name for the obj ect usi ng the stri ng name passed as an argument. Cal li ng the constructor
sc_object(const char*) with an empty string shall have the same behavior as the def aul t constructor; that i s,
the stri ng name shall be set to "object".
The rules f or composing a hi erarchi cal name are given i n 5.17.
I f the constructor needs to substi tute a new string name i n place of the ori gi nal stri ng name as the resul t of a
name clash, the constructor shall generate a single warni ng.
sc_object( const sc_obj ect& arg );
The copy constructor shal l create a new sc_object as if i t had been created by the cal l sc_object(
arg.basename() ). I n other words, the new obj ect shal l be a chi ld of a module i nstance i f created
f rom the constructor of that modul e or a chi ld of a process instance i f created from the functi on asso-
ciated wi th that process. The string name of the existi ng obj ect shall be used as the seed f or the string
name of the new object. Attri butes or chi ldren of the existing object shall not be copied to the new
object.
sc_object& operator= ( const sc_obj ect& );
The assi gnment operator shall not modif y the hierarchi cal name or the parent of the destinati on
object in the object hi erarchy. In other words, the desti nation object shall retain i ts current position
in the obj ect hierarchy. Attributes and chi ldren of the destination object shall not be modi fi ed.
operator= shall return a ref erence to *this.
virtual ~sc_object();
The destructor shall del ete the obj ect, shall del ete any attribute collection attached to the object, and
shal l remove the object f rom the obj ect hierarchy such that it is no l onger a chil d.
NOTEIf an implementation were to create internal objects of class sc_object, the i mpl ementati on woul d be obl i ged by
the rul es of thi s subcl ause to excl ude those obj ects f rom the obj ect hi erarchy and from the namespace of hierarchi cal
names. Thi s woul d necessitate an extensi on to the semanti cs of cl ass sc_object, and the i mplementati on woul d be
obl iged to make such an extension transparent to the appl i cati on.
5.16.5 name, basename, and kind
const char* name() const;
Member function name shall return the hi er ar chi cal name of the sc_object i nstance i n the object
hierarchy.
const char* basename() const;
Member f uncti on basenameshall return the stri ng name of the sc_object instance. Thi s i s the stri ng
name created when the sc_object instance was constructed.
virtual const char* kind() const;
Member f unction kind returns a character string i dentif yi ng the ki nd of the sc_object. Member
f uncti on kind of class sc_object shal l return the stri ng "sc_object". Every cl ass that is part of the
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


127
Copyright 2012 IEEE. All rights reserved.
implementati on and that i s derived f rom cl ass sc_object shal l override member f uncti on kind to
return an appropriate string.
Exampl e:
#include "systemc.h"
SC_MODULE(Mod)
{
sc_port<sc_si gnal _i n_i f<i nt> > p;
SC_CTOR(Mod) // p.name() returns "top.mod.p"
: p("p") // p.basename() returns "p"
{ } // p.ki nd() returns "sc_port"
} ;
SC_MODULE(Top)
{
Mod * mod; // mod->name() returns "top.mod"
sc_signal <int> si g; // si g.name() returns "top.sig"
SC_CTOR(Top)
: sig("si g")
{
mod = new Mod("mod");
mod->p(si g);
}
} ;
int sc_main(i nt argc, char* argv[] )
{
Top top("top"); // top.name() returns "top"
sc_start();
return 0;
}
5.16.6 print and dump
virtual void print( std::ostream& = std::cout ) const;
Member f uncti on print shall print the character string returned by member function name to the
stream passed as an argument. No additi onal characters shall be printed.
virtual void dump( std::ostream& = std::cout ) const;
Member f uncti on dump shal l pri nt at least the name and the kind of the sc_object to the stream
passed as an argument. The formatting shall be impl ementation-dependent. The purpose of dump is
to all ow an impl ementation to pri nt diagnostic informati on to help the user debug an applicati on.
5.16.7 Functions for object hierarchy traversal
The four f uncti ons in this subcl ause return i nformation that supports the traversal of the object hierarchy. An
impl ementation shall allow each of these f our functi ons to be call ed at any stage during el aboration or
simul ation. I f cal led before el aboration i s complete, they shal l return inf ormati on concerning the partiall y
constructed obj ect hierarchy as i t exi sts at the ti me the f uncti ons are cal led. In other words, a f uncti on shal l
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


128
Copyright 2012 IEEE. All rights reserved.
return poi nters to any objects that have been constructed before the time the function is call ed but wil l
excl ude any objects constructed after the function is cal led.
virtual const std::vector<sc_object* >& get_child_objects() const;
Member f uncti on get_child_objectsshall return a std::vector containi ng a pointer to every i nstance
of class sc_object that i s a child of the current sc_object i n the obj ect hierarchy. The vi rtual functi on
sc_object::get_child_objects shall return an empty vector but shal l be overri dden by the
impl ementation in those cl asses derived from cl ass sc_object that do have chi ldren, that i s, class
sc_module and the impl ementation-defi ned classes associ ated with spawned and unspawned
process instances.
virtual const std::vector<sc_event* >& get_child_events() const;
Member functi on get_child_eventsshall return a std::vector contai ni ng a poi nter to every object of
type sc_event that i s a hierarchi cal ly named event and whose parent is the current obj ect. The virtual
f uncti on sc_object::get_child_events shall return an empty vector but shal l be overri dden by the
impl ementation in those cl asses derived from cl ass sc_object that do have chi ldren, that i s, class
sc_module and the impl ementation-defi ned classes associ ated with spawned and unspawned
process instances.
sc_object* get_parent_object() const;
Member function get_parent_object shal l return a pointer to the sc_object that i s the parent of the
current object in the obj ect hierarchy. If the current obj ect i s a top-level object, member function
get_parent_object shall return the nul l pointer. If the parent object i s a process instance and that
process has terminated, get_parent_object shal l return a poi nter to that process instance. A process
instance shall not be del eted (nor any associ ated process handl es i nval idated) while the process has
surviving chi ldren, but it may be deleted once al l i ts chi ld obj ects have been deleted.
const std::vector<sc_object* >& sc_get_top_level_objects();
Function sc_get_top_level_objectsshal l return a std::vector containing pointers to all of the top-
level sc_objects.
sc_object* sc_find_object( const char* );
Function sc_find_object shal l return a pointer to the sc_object that has a hierarchi cal name that
exactl y matches the val ue of the string argument or shall return the nul l poi nter if there is no
sc_object havi ng a matching name.
Exampl es:
void scan_hi erarchy(sc_object* obj ) // Traverse the enti re obj ect subhierarchy
// bel ow a given obj ect
{
std::vector<sc_obj ect* > chil dren = obj ->get_chi ld_obj ects();
f or ( unsi gned i = 0; i < chi ldren.si ze(); i++ )
if ( chil dren[ i] )
scan_hi erarchy( children[ i] );
}
std::vector<sc_obj ect* > tops = sc_get_top_l evel_objects();
f or ( unsi gned i = 0; i < tops.size(); i++ )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


129
Copyright 2012 IEEE. All rights reserved.
if ( tops[i ] )
scan_hi erarchy( tops[ i] ); // Traverse the object hierarchy bel ow
// each top-l evel object
sc_object* obj = sc_fi nd_object("f oo.f oobar"); // Find an obj ect gi ven i ts hi erarchical name
sc_module* m;
if (m = dynamic_cast<sc_module* >(obj )) // Test whether the given object i s a modul e
... // The given obj ect i s a modul e

sc_object* parent = obj->get_parent_obj ect(); // Get the parent of the gi ven obj ect
if (parent) // parent is a null poi nter f or a top-level obj ect
std::cout << parent->name() << " " << parent->kind();// Print the name and kind
5.16.8 Member functions for attributes
bool add_attribute( sc_attr_base& );
Member f unction add_attributeshal l attempt to attach to the obj ect of class sc_object the attri bute
passed as an argument. I f an attri bute having the same name as the new attribute is already attached
to this obj ect, member function add_attributeshal l not attach the new attribute and shall return the
val ue false. Otherwise, member function add_attribute shal l attach the new attri bute and shall
return the value true. The argument should be an object of cl ass sc_attribute, not sc_attr_base.
The l if etime of an attribute shall extend unti l the attribute has been completel y removed f rom al l
objects. If an appli cati on del etes an attribute that is stil l attached to an obj ect, the behavi or of the
impl ementation shall be undef ined.
sc_attr_base* get_attribute( const std::stri ng& );
const sc_attr_base* get_attribute( const std::string& ) const;
Member functi on get_attribute shall attempt to retrieve f rom the object of class sc_object an
attri bute havi ng the name passed as an argument. If an attribute with the gi ven name is attached to
thi s object, member f unction get_attribute shall return a pointer to that attribute. Otherwi se,
member f uncti on get_attributeshall return the null poi nter.
sc_attr_base* remove_attribute( const std::string& );
Member f uncti on remove_attributeshall attempt to remove f rom the obj ect of class sc_object an
attri bute havi ng the name passed as an argument. If an attribute with the gi ven name is attached to
thi s obj ect, member function remove_attribute shal l return a pointer to that attri bute and remove
the attribute f rom this obj ect. Otherwi se, member functi on remove_attributeshall return the nul l
pointer.
void remove_all_attributes();
Member functi on remove_all_attributes shall remove al l attributes f rom the obj ect of class
sc_object.
int num_attributes() const;
Member functi on num_attributes shall return the number of attributes attached to the object of
class sc_object.
sc_attr_cltn& attr_cltn();
const sc_attr_cl tn& attr_cltn() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


130
Copyright 2012 IEEE. All rights reserved.
Member f unction attr_cltn shal l return the col lecti on of attributes attached to the object of cl ass
sc_object (see 5.20).
NOTEA pointer returned fromfunction get_attributeneeds to be cast to type sc_attribute<T>* in order to
access data member valueof cl ass sc_attribute.
Exampl e:
sc_signal <int> si g;
...
// Add an attribute to an sc_object
sc_attri bute<i nt> a("number", 1);
sig.add_attribute(a);
// Retri eve the attri bute by name and modif y the value
sc_attri bute<i nt>* ap;
ap = (sc_attribute<i nt>* )sig.get_attribute("number");
++ ap->value;
5.17 Hierarachical naming of objects and events
This clause describes the rul es that determi ne the hierarchi cal nami ng of obj ects of type sc_object and of
hierarchi call y named events. The nami ng of events that are not hi erarchical ly named is descri bed in 5.10.4.
namespace sc_core {
bool sc_hierarchical_name_exists( const char* );
} // namespace sc_core
Function sc_hierarchical_name_exists shall return the val ue true if and only if the value of the string
argument exactl y matches the hierarchi cal name of an sc_object or of a hierarchi cal ly named event. I f the
val ue of the string argument exactly matches an impl ementation-def ined event name, f unction
sc_hierarchical_name_exists shall return the value false unless the string argument al so matches a
hierarchi cal name.
A hierarchi cal name shal l be composed of a set of string names separated by the period character '.', starting
wi th the stri ng name of a top-l evel sc_object i nstance and including the string name of each modul e instance
or process i nstance descendi ng down through the object hi erarchy unti l the current sc_object or sc_event is
reached. The hierarchi cal name shall end with the string name of the sc_object or sc_event itsel f.
Hi erarchical names are case-sensi ti ve.
I t shal l be an error i f a stri ng name i ncl udes the peri od character (.) or any white-space characters. I t is
strongly recommended that an appli cati on l imit the character set of a string name to the fol lowing:
a) Lowercase letters az
b) Uppercase letters AZ
c) Decimal digits 09
d) Underscore character _
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


131
Copyright 2012 IEEE. All rights reserved.
An i mplementati on may generate a warning if a stri ng name contai ns characters outsi de thi s set but is not
obl iged to do so.
There shall be a si ngl e gl obal namespace f or hierarchi cal names. Each sc_object and each hierarchi cal ly
named sc_event shall have a uni que non-empty hierarchical name. An i mplementati on shal l not add any
names to thi s namespace other than the hierarchi cal names of sc_objects expli ci tl y constructed by an
appl ication and the hierarchi cal names of hierarchicall y named events.
The constructor shall bui ld a hi erarchi cal name f rom the stri ng name (either passed in as an argument or the
def aul t name "object" f or an sc_object or "event" for an sc_event) and test whether that hierarchi cal name
is unique. If it i s unique, that hi erarchi cal name shall become the hi erarchical name of the object. If not, the
constructor shall cal l function sc_gen_unique_name, passi ng the stri ng name as a seed. It shal l use the
val ue returned as a replacement f or the string name and shal l repeat thi s process unti l a uni que hi erarchical
name i s generated.
I f f uncti on sc_gen_unique_name i s call ed more than once i n the course of constructing any gi ven object,
the choi ce of seed passed to sc_gen_unique_name on the second and subsequent call s shal l be
implementation-def ined but shal l i n any case be ei ther the stri ng name passed as the seed on the fi rst such
cal l or shall be one of the stri ng names returned from sc_gen_unique_namei n the course of constructi ng
the given object. In other words, the fi nal stri ng name shall have the original string name as a prefi x.
5.18 sc_attr_base
5.18.1 Description
Cl ass sc_attr_basei s the base cl ass f or attributes, stori ng onl y the name of the attri bute. The name is used as
a key when retrieving an attri bute f rom an obj ect. Every attribute attached to a specif ic obj ect shall have a
unique name but two or more attri butes wi th identical names may be attached to distinct obj ects.
5.18.2 Class definition
namespace sc_core {
class sc_attr_base
{
publ ic:
sc_attr_base( const std::string& );
sc_attr_base( const sc_attr_base& );
virtual ~sc_attr_base();
const std::string& name() const;
pri vate:
// Di sabl ed
sc_attr_base();
sc_attr_base& operator= ( const sc_attr_base& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


132
Copyright 2012 IEEE. All rights reserved.
5.18.3 Member functions
The constructors f or classsc_attr_baseshal l set the name of the attri bute to the string passed as an argument
to the constructor.
Member f uncti on nameshal l return the name of the attribute.
5.19 sc_attribute
5.19.1 Description
Cl ass sc_attribute stores the val ue of an attribute. I t i s derived from class sc_attr_base, whi ch stores the
name of the attri bute. An attri bute can be attached to an obj ect of class sc_object.
5.19.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_attribute
: publi c sc_attr_base
{
publ ic:
sc_attribute( const std::string& );
sc_attribute( const std::string&, const T& );
sc_attribute( const sc_attribute<T>& );
virtual ~sc_attribute();
T val ue;
pri vate:
// Di sabl ed
sc_attribute();
sc_attri bute<T>& operator= ( const sc_attribute<T>& );
} ;
} // namespace sc_core
5.19.3 Template parameters
The argument passed to template sc_attributeshal l be of a copy-constructi bl e type.
5.19.4 Member functions and data members
The constructors shal l set the name and value of the attri bute using the name (of type std::string) and val ue
(of type T) passed as arguments to the constructor. I f no value i s passed to the constructor, the default
constructor (of type T) shall be cal led to construct the value.
Data member valueis the val ue of the attri bute. An appl ication may read or assi gn this publi c data member.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


133
Copyright 2012 IEEE. All rights reserved.
5.20 sc_attr_cltn
5.20.1 Description
Cl ass sc_attr_cltn is a container class for attri butes, as used in the implementation of cl ass sc_object. It
provides i terators f or traversing al l of the attri butes in an attribute col lection.
5.20.2 Class definition
namespace sc_core {
class sc_attr_cltn
{
publ ic:
typedef sc_attr_base* elem_type;
typedef el em_type* iterator;
typedef const elem_type* const_iterator;
iterator begin();
const_i terator begin() const;
iterator end();
const_i terator end() const;
// Other members
I mpl ementati on-defi ned
pri vate:
// Di sabl ed
sc_attr_cltn( const sc_attr_cl tn& );
sc_attr_cltn& operator= ( const sc_attr_cl tn& );
} ;
} // namespace sc_core
5.20.3 Constraints on usage
An appl ication shall not expli ci tly create an object of class sc_attr_cltn. An appli cation may use the
iterators to traverse the attribute collecti on returned by member f uncti on attr_cltn of class sc_object.
An i mplementati on is only obl iged to keep an attri bute col lecti on val id unti l a new attri bute is attached to the
sc_object or an existi ng attri bute i s removed f rom the sc_object in questi on. Hence, an appl ication should
traverse the attribute col lecti on i mmedi ately on return f rom member f uncti on attr_cltn.
5.20.4 Iterators
iterator begin();
const_i terator begin() const;
iterator end();
const_i terator end() const;
Member function beginshall return a pointer to the fi rst el ement of the coll ecti on. Each el ement of
the col lecti on i s i tsel f a poi nter to an attribute.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


134
Copyright 2012 IEEE. All rights reserved.
Member functi on end shall return a poi nter to the element f oll owing the last el ement of the
col lecti on.
Exampl e:
sc_signal <int> si g;
...
// Iterate through al l the attri butes of an sc_object
sc_attr_cltn& c = sig.attr_cl tn();
f or (sc_attr_cltn::iterator i = c.begi n(); i < c.end(); i++)
{
sc_attri bute<i nt>* ap = dynamic_cast<sc_attri bute<i nt>* >(* i );
if (ap) std::cout << ap->name() << "=" << ap->val ue << std::endl ;
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


135
Copyright 2012 IEEE. All rights reserved.
6. Predefined channel class definitions
6.1 sc_signal_in_if
6.1.1 Description
Cl ass sc_signal_in_if is an i nterf ace proper used by predef ined channels, including sc_signal. Interface
sc_signal_in_if gives read access to the value of a si gnal.
6.1.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_signal_in_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual const T& read() const = 0;
virtual const sc_event& value_changed_event() const = 0;
virtual bool event() const = 0;
protected:
sc_signal_in_if();
pri vate:
// Di sabl ed
sc_signal_in_if( const sc_si gnal _i n_i f<T>& );
sc_signal _in_if <T>& operator= ( const sc_si gnal_i n_i f<T>& );
} ;
} // namespace sc_core
6.1.3 Member functions
The f oll owing member functions are all pure vi rtual functi ons. The descriptions refer to the expected
def ini ti ons of the functions when overri dden i n a channel that impl ements this i nterf ace. The preci se
semanti cs wi ll be channel -speci fi c.
Member f uncti on read shall return a ref erence to the current val ue of the channel.
Member functi on value_changed_event shall return a reference to an event that i s noti fi ed whenever the
val ue of the channel i s written or modifi ed.
Member f uncti on event shall return the val ue true if and onl y i f the val ue of the channel was written or
modif ied in the immediatel y preceding delta cycl e and at the current si mulati on time.
NOTEThe value of the channel may have been modified i n the eval uati on phase or i n the update phase of the
i mmedi atel y precedi ng del ta cycl e, dependi ng on whether it i s a hi erarchi cal channel or a pri mi ti ve channel (f or
exampl e, sc_signal).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


136
Copyright 2012 IEEE. All rights reserved.
6.2 sc_signal_in_if<bool> and sc_signal_in_if<sc_dt::sc_logic>
6.2.1 Description
Cl asses sc_signal_in_if<bool> and sc_signal_in_if<sc_dt::sc_logic> are interfaces proper that provide
addi ti onal member f uncti ons appropriate f or two-val ued signal s.
6.2.2 Class definition
namespace sc_core {
templ ate <>
class sc_signal_in_if<bool>
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual const T& read() const = 0;
virtual const sc_event& value_changed_event() const = 0;
virtual const sc_event& posedge_event() const = 0;
virtual const sc_event& negedge_event() const = 0;
virtual bool event() const = 0;
virtual bool posedge() const = 0;
virtual bool negedge() const = 0;
protected:
sc_signal_in_if();
pri vate:
// Di sabl ed
sc_signal_in_if( const sc_si gnal_i n_i f<bool>& );
sc_signal _in_if <bool >& operator= ( const sc_si gnal_i n_i f<bool>& );
} ;
templ ate <>
class sc_signal_in_if<sc_dt::sc_logic>
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual const T& read() const = 0;
virtual const sc_event& value_changed_event() const = 0;
virtual const sc_event& posedge_event() const = 0;
virtual const sc_event& negedge_event() const = 0;
virtual bool event() const = 0;
virtual bool posedge() const = 0;
virtual bool negedge() const = 0;
protected:
sc_signal_in_if();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


137
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_signal_in_if( const sc_si gnal_i n_i f<sc_dt::sc_logic>& );
sc_signal _in_if <sc_dt::sc_logi c>& operator= ( const sc_si gnal_i n_i f<sc_dt::sc_logic>& );
} ;
} // namespace sc_core
6.2.3 Member functions
The f ol lowi ng li st is i ncomplete. For the remai ning member functi ons, refer to the defi nitions of the member
f uncti ons for cl ass sc_signal_in_if (see 6.1.3).
Member functi on posedge_event shall return a ref erence to an event that i s notif ied whenever the val ue of
the channel (as returned by member f unction read) changes and the new val ue of the channel i s trueor '1'.
Member functi on negedge_event shall return a ref erence to an event that is notif ied whenever the val ue of
the channel (as returned by member f unction read) changes and the new val ue of the channel i s falseor '0'.
Member functi on posedgeshall return the val ue true if and onl y i f the value of the channel changed in the
update phase of the immedi ately preceding del ta cycl e and at the current simul ation ti me, and the new val ue
of the channel is trueor '1'.
Member function negedgeshall return the value truei f and onl y if the val ue of the channel changed in the
update phase of the immedi ately preceding del ta cycl e and at the current simul ation ti me, and the new val ue
of the channel is false or '0'.
6.3 sc_signal_inout_if
6.3.1 Description
Cl ass sc_signal_inout_if i s an i nterf ace proper that i s used by predef ined channels, i ncludi ng sc_signal.
I nterf ace sc_signal_inout_if gives both read and wri te access to the value of a si gnal , and it is derived from
a further interface proper sc_signal_write_if.
6.3.2 Class definition
namespace sc_core {
enum sc_writer_policy
{
SC_ONE_WRI TER,
SC_MANY_WRITERS
} ;
templ ate <class T>
class sc_signal_write_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual sc_writer_pol icy get_writer_policy() const { return SC_ONE_WRI TER; }
virtual void write( const T& ) = 0;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


138
Copyright 2012 IEEE. All rights reserved.
protected:
sc_signal_write_if();
pri vate:
// Di sabl ed
sc_signal_write_if( const sc_si gnal _wri te_i f<T>& );
sc_signal _wri te_if <T>& operator= ( const sc_si gnal_write_i f<T>& );
} ;
templ ate <class T>
class sc_signal_inout_if
: publi c sc_signal_in_i f<T> , publ ic sc_si gnal _write_i f<T>
{
protected:
sc_signal_inout_if();
pri vate:
// Di sabl ed
sc_signal_inout_if( const sc_si gnal _i nout_if <T>& );
sc_signal _inout_if <T>& operator= ( const sc_si gnal _i nout_if <T>& );
} ;
} // namespace sc_core
6.3.3 Member functions
The f ollowi ng text describes the expected def ini ti ons of the member f unctions when overri dden i n a channel
that i mplements this interface. The precise semantics will be channel-speci fi c.
virtual sc_writer_pol icy get_writer_policy() const { return SC_ONE_WRITER; }
Member f uncti on get_writer_policy shall return the val ue of the writer pol icy f or the channel
instance. Unless overri dden i n a channel , this f unction shall return the val ue SC_ONE_WRITER f or
backward compatibil ity with previous versi ons of thi s standard.
virtual void write( const T& ) = 0;
Member function writeshal l modi fy the val ue of the channel such that the channel appears to have
the new val ue (as returned by member function read) i n the next del ta cycl e but not before then. The
new val ue is passed as an argument to the f unction.
Member functi on writeshall honor the val ue of the writer poli cy set for the channel i nstance; that i s,
it shall permi t either one wri ter or many wri ters.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


139
Copyright 2012 IEEE. All rights reserved.
6.4 sc_signal
6.4.1 Description
Cl ass sc_signal is a predef ined primiti ve channel i ntended to model the behavior of a si ngl e pi ece of wi re
carryi ng a digital el ectronic signal .
6.4.2 Class definition
namespace sc_core {
templ ate <cl ass T, sc_wri ter_poli cy WRITER_POLICY = SC_ONE_WRITER>
class sc_signal
: publi c sc_signal_inout_i f<T>, publ ic sc_pri m_channel
{
publ ic:
sc_signal();
expl icit sc_signal( const char* );
virtual ~sc_signal();
virtual void register_port( sc_port_base&, const char* );
virtual const T& read() const;
operator const T& () const;
virtual sc_writer_pol icy get_writer_policy() const;
virtual void write( const T& );
sc_signal<T,WRI TER_POLICY>& operator= ( const T& );
sc_signal<T,WRI TER_POLICY>& operator= ( const sc_si gnal<T,WRITER_POLI CY>& );
virtual const sc_event& default_event() const;
virtual const sc_event& value_changed_event() const;
virtual bool event() const;
virtual void print( std::ostream& = std::cout ) const;
virtual void dump( std::ostream& = std::cout ) const;
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_signal( const sc_si gnal <T,WRI TER_POLI CY>& );
} ;
templ ate <cl ass T, sc_writer_pol icy WRI TER_POLICY>
inl ine std::ostream& operator<< ( std::ostream&, const sc_signal <T,WRI TER_POLI CY>& );
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


140
Copyright 2012 IEEE. All rights reserved.
6.4.3 Template parameter T
The argument passed to templatesc_signal shall be either a C++ type for whi ch the predefi ned semantics f or
assignment and equali ty are adequate (for exampl e, a f undamental type or a pointer), or a type T that obeys
each of the fol lowing rul es:
a) The f oll owing equali ty operator shall be defi ned for the type T and shoul d return the val ue trueif
and onl y if the two val ues being compared are to be regarded as indisti nguishabl e for the purposes of
signal propagation (that is, an event occurs onl y i f the val ues are dif ferent). The impl ementation
shal l use this operator wi thi n the impl ementation of the si gnal to determine whether an event has
occurred.
bool T::operator== ( const T& );
b) The f ol lowi ng stream operator shall be defi ned and should copy the state of the obj ect given as the
second argument to the stream given as the fi rst argument. The way in whi ch the state i nf ormation i s
f ormatted is undef ined by this standard. The i mplementati on shal l use this operator i n i mplementi ng
the behavior of the member f unctions print and dump.
std::ostream& operator<< ( std::ostream&, const T& );
c) I f the def aul t assignment semantics are i nadequate (i n the sense given in this subcl ause), the
f ol lowi ng assignment operator should be def ined for the type T. I n either case (def aul t assignment or
expl icit operator), the semantics of assi gnment shoul d be suf fi ci ent to assi gn the state of an object of
type T such that the val ue of the left operand i s indistingui shable from the value of the ri ght operand
usi ng the equal ity operator mentioned i n thi s subclause. The i mplementati on shall use this
assignment operator wi thi n the i mplementati on of the signal when assi gni ng or copying values of
type T.
const T& operator= ( const T& );
d) I f any constructor f or type T exi sts, a def aul t constructor for type T shal l be defi ned.
e) I f the cl ass template is used to defi ne a signal to which a port of type sc_in, sc_inout, or sc_out is
bound, the foll owing function shall be defi ned:
void sc_trace( sc_trace_f il e* , const T&, const std::string& );
NOTE 1The equality and assignment operators are not obl i ged to compare and assi gn the compl ete state of the obj ect,
al though they shoul d typi call y do so. For exampl e, diagnosti c i nf ormati on may be associated wi th an obj ect that is not to
be propagated through the si gnal .
NOTE 2The SystemC data types proper (sc_dt::sc_int, sc_dt::sc_logic, and so f orth) all conf orm to the rul e set j ust
gi ven.
NOTE 3It is illegal to pass class sc_module (for exampl e) as a templ ate argument to cl ass sc_signal, because
sc_module::operator== does not exi st. I t i s l egal to pass type sc_module* through a si gnal , al though this woul d be
regarded as an abuse of the module hi erarchy and thus bad practi ce.
6.4.4 Reading and writing signals
A signal is r ead by call ing member functi on read or operator const T& ().
A si gnal i swr i tten by cal li ng member function writeor operator= of the given signal obj ect. If the templ ate
argument WRI TER_POLI CY has the value SC_ONE_WRITER, it shal l be an error to wri te to a given
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


141
Copyright 2012 IEEE. All rights reserved.
signal instance from more than one process instance at any ti me during si mulation. I f the templ ate argument
WRITER_POLICY has the value SC_MANY_WRITERS, it shal l be an error to wri te to a given signal
instance f rom more than one process i nstance during any gi ven eval uation phase, but dif ferent process
instances may wri te to a given si gnal i nstance during di f ferent delta cycl es. A si gnal may be written duri ng
elaboration (including the elaborati on and si mulation cal lbacks as described in 4.4) to ini ti al ize the val ue of
the si gnal . A signal may be wri tten from function sc_main during el aboration or whil e si mul ation i s paused,
that i s, before or after the cal l to f uncti on sc_start.
Signals are typicall y read and written duri ng the eval uation phase, but the val ue of the si gnal is onl y
modif ied during the subsequent update phase. If and onl y i f the val ue of the si gnal actual ly changes as a
result of being written, an event (the val ue-changed event) shall be notif ied in the del ta notif i cati on phase
that i mmediately f ol lows.
I f a gi ven signal is written on mul ti pl e occasions withi n a particular eval uation phase, or during el aboration,
or f rom f unction sc_main, the val ue to which the si gnal changes in the i mmediately f ollowi ng update phase
shal l be determined by the most recent wri te; that i s, the l ast wr i te wi ns.
NOTE 1The specialized ports sc_inout and sc_out have a member f uncti on initializef or the purpose of i ni ti al i zi ng
the value of a signal duri ng el aborati on.
NOTE 2If the value of a signal is read duri ng el aborati on, the val ue returned wi l l be the i niti al val ue of the si gnal as
created by the def aul t constructor f or type T.
NOTE 3If a given signal is written and read during the same evaluati on phase, the ol d val ue wi l l be read. The val ue
written wi l l not be avai lable to be read unti l the subsequent eval uati on phase.
6.4.5 Constructors
sc_signal();
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_pri m_channel ( sc_gen_uni que_name( "si gnal" ) )
expl icit sc_signal( const char* name_ );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_pri m_channel ( name_ )
Both constructors shal l initial ize the val ue of the signal by cal li ng the def aul t constructor for type T f rom
their initial izer li sts.
6.4.6 register_port
virtual void register_port( sc_port_base&, const char* );
Member functi on register_port of cl ass sc_interface shall be overridden in cl ass sc_signal and
shal l perf orm the fol lowing error check. If the templ ate argument WRI TER_POLI CY has the value
SC_ONE_WRI TER, i t shall be an error to bind more than one port of type sc_signal_inout_if to a
given si gnal . If the WRI TER_POLI CY has the val ue SC_MANY_WRITERS, one or more ports of
type sc_signal_inout_if may be bound to a gi ven signal .
6.4.7 Member functions for reading
virtual const T& read() const;
Member f uncti on readshall return a reference to the current value of the signal but shall not modi fy
the state of the si gnal .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


142
Copyright 2012 IEEE. All rights reserved.
operator const T& () const;
operator const T& () shall return a reference to the current value of the si gnal (as returned by
member f uncti on read).
6.4.8 Member functions for writing
virtual sc_writer_pol icy get_writer_policy() const;
Member f unction get_writer_policy shal l return the val ue of the WRI TER_POLICY template
parameter f or the channel instance.
virtual void write( const T& );
Member function writeshal l modi fy the val ue of the signal such that the signal appears to have the
new val ue (as returned by member function read) i n the next delta cycle but not bef ore then. Thi s
shal l be accompli shed usi ng the update request mechani sm of the primitive channel . The new value
is passed as an argument to member f uncti on write. Member f unction write may be call ed during
elaborati on, in which case the update request shall be executed duri ng the i ni ti al izati on phase.
operator=
The behavi or of operator= shall be equi val ent to the foll owing def initions:
sc_signal<T,WRI TER_POLICY>& operator= ( const T& arg ) { write( arg ); return * thi s; }
sc_signal<T,WRI TER_POLICY>& operator= ( const sc_si gnal<T,WRITER_POLI CY>& arg ) {
write( arg.read() ); return * this; }
virtual void update();
Member function updateof class sc_prim_channel shal l be overridden by the impl ementation in
class sc_signal to impl ement the updati ng of the si gnal value that occurs as a result of the si gnal
bei ng wri tten. Member f unction updateshal l modif y the current val ue of the si gnal such that it gets
the new value (as passed as an argument to member f uncti on write), and i t shall cause the val ue-
changed event to be notif ied i n the i mmedi ately foll owing del ta notif ication phase i f the val ue of the
signal has changed.
NOTEMember function update i s cal l ed by the schedul er but typi cal l y i s not cal l ed by an appl i cati on.
However, member f uncti on updateof cl ass sc_signal may be cal l ed from member f uncti on updateof a cl ass
deri ved f rom cl ass sc_signal.
6.4.9 Member functions for events
virtual const sc_event& default_event() const;
virtual const sc_event& value_changed_event() const;
Member f uncti ons default_event and value_changed_event shall both return a ref erence to the
value-changed event.
virtual bool event() const;
Member functi on event shall return the value true if and only if the val ue of the si gnal changed i n
the update phase of the immedi atel y preceding delta cycl e and at the current si mulation time; that is,
a member f uncti on writeor operator= was call ed in the immedi ately precedi ng evaluation phase,
and the value wri tten or assi gned was dif ferent f rom the previous value of the signal .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


143
Copyright 2012 IEEE. All rights reserved.
NOTEMember function event returns tr ue when cal l ed f rom a process that was executed as a di rect resul t of
the val ue-changed event of that same si gnal i nstance bei ng notif i ed.
6.4.10 Diagnostic member functions
virtual void pr int( std::ostream& = std::cout ) const;
Member function pr int shal l print the current val ue of the signal to the stream passed as an
argument by call ing oper ator << (std::ostream& , T& ). No additional characters shall be pri nted.
virtual void dump( std::ostream& = std::cout ) const;
Member f unction dump shall pri nt at least the hi erarchical name, the current value, and the new
val ue of the si gnal to the stream passed as an argument. The formatti ng shall be i mplementati on-
def ined.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_signal" .
6.4.11 operator<<
templ ate <cl ass T, sc_writer_pol icy WRI TER_POLICY>
inl ine std::ostream& oper ator << ( std::ostream& , const sc_ si gnal <T,WRITER_POLI CY>& );
oper ator << shal l pri nt the current value of the signal passed as the second argument to the stream
passed as the f irst argument by cal li ng oper ator << ( std::ostream& , T& ).
Exampl e:
SC_MODULE(M)
{
sc_signal <int> si g;
SC_CTOR(M)
{
SC_THREAD(wri ter);
SC_THREAD(reader);
SC_METHOD(writer2);
sensitive << si g; // Sensitive to the default event
}
void wri ter()
{
wait(50, SC_NS);
sig.wri te(1);
sig.wri te(2);
wait(50, SC_NS);
sig = 3; // Calls operator= ( const T& )
}
void reader()
{
wait(sig.value_changed_event());
int i = si g.read(); // Reads a value of 2
wait(sig.value_changed_event());
i = sig; // Calls operator const T& (), whi ch returns a val ue of 3
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


144
Copyright 2012 IEEE. All rights reserved.
void wri ter2()
{
sig.wri te(sig + 1); // An error. A signal shall not have multi ple wri ters
}
} ;
NOTEThe following classes are related to class sc_signal:
The classes sc_signal<bool,WRI TER_POLICY> and sc_signal<sc_dt::sc_logic,WRI TER_POLICY>
provi de addi ti onal member f uncti ons appropri ate f or two-val ued si gnal s.
The class sc_buffer i s derived f rom sc_signal but di ff ers i n that the val ue-changed event i s noti f i ed whenever
the buff er i s wri tten whether or not the value of the buf f er has changed.
The class sc_clock i s deri ved f rom sc_signal and generates a peri odi c cl ock si gnal .
The class sc_signal_r esolved al l ows mul ti pl e wri ters.
The classes sc_in, sc_out, and sc_inout are speci al i zed ports that may be bound to signal s, and whi ch provi de
f uncti ons to access the member f uncti ons of the si gnal conveni entl y through the port.
6.5 sc_signal<bool,WRITER_POLICY> and
sc_signal<sc_dt::sc_logic,WRITER_POLICY>
6.5.1 Description
Cl asses sc_signal<bool,W RI TER_POLI CY > and sc_signal<sc_dt::sc_logic,W RI TER_POLI CY> are
predef ined primi ti ve channels that provi de addi tional member functi ons appropriate for two-valued signals.
6.5.2 Class definition
namespace sc_core {
templ ate <sc_writer_poli cy WRITER_POLICY>
class sc_signal<bool,WRITER_POLICY>
: publi c sc_signal_inout_if <bool >, publ ic sc_prim_channel
{
publ ic:
sc_signal();
expl icit sc_signal( const char* );
virtual ~sc_signal();
virtual void register _por t( sc_port_base&, const char* );
virtual const bool& read() const;
oper ator const bool& () const;
virtual sc_writer_pol icy get_wr iter _policy() const;
virtual void wr ite( const bool & );
sc_signal<bool,WRI TER_POLICY>& oper ator = ( const bool& );
sc_signal<bool,WRI TER_POLICY>& oper ator = ( const sc_si gnal <bool,WRITER_POLI CY>& );
virtual const sc_event& default_event() const;
virtual const sc_event& value_changed_event() const;
virtual const sc_event& posedge_event() const;
virtual const sc_event& negedge_event() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


145
Copyright 2012 IEEE. All rights reserved.
virtual bool event() const;
virtual bool posedge() const;
virtual bool negedge() const;
virtual void pr int( std::ostream& = std::cout ) const;
virtual void dump( std::ostream& = std::cout ) const;
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_signal( const sc_si gnal <bool ,WRI TER_POLI CY>& );
} ;
templ ate <sc_writer_poli cy WRITER_POLICY>
class sc_signal<sc_dt::sc_logic,WRITER_POLICY>
: publi c sc_signal_inout_if <sc_dt::sc_l ogi c,WRI TER_POLICY>, publ ic sc_pri m_channel
{
publ ic:
sc_signal();
expl icit sc_signal( const char* );
virtual ~sc_signal();
virtual void register _por t( sc_port_base&, const char* );
virtual const sc_dt::sc_logic& read() const;
oper ator const sc_dt::sc_logic& () const;
virtual void wr ite( const sc_dt::sc_l ogi c& );
sc_signal <sc_dt::sc_l ogi c,WRITER_POLICY>& oper ator = ( const sc_dt::sc_logi c& );
sc_signal <sc_dt::sc_l ogi c,WRITER_POLICY>&
oper ator = ( const sc_si gnal<sc_dt::sc_logic,WRITER_POLICY>& );
virtual const sc_event& default_event() const;
virtual const sc_event& value_changed_event() const;
virtual const sc_event& posedge_event() const;
virtual const sc_event& negedge_event() const;
virtual bool event() const;
virtual bool posedge() const;
virtual bool negedge() const;
virtual void pr int( std::ostream& = std::cout ) const;
virtual void dump( std::ostream& = std::cout ) const;
virtual const char* kind() const;
protected:
virtual void update();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


146
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_signal( const sc_si gnal <sc_dt::sc_logic,WRI TER_POLICY>& );
} ;
} // namespace sc_core
6.5.3 Member functions
The f ol lowi ng li st is i ncomplete. For the remai ning member functi ons, refer to the defi nitions of the member
f uncti ons for cl ass sc_signal (see 6.4).
virtual const sc_event& posedge_event () const;
Member f unction posedge_event shal l return a reference to an event that is notif ied whenever the
val ue of the signal (as returned by member f uncti on read) changes and the new value of the signal i s
true or ' 1' .
virtual const sc_event& negedge_event() const;
Member function negedge_event shal l return a ref erence to an event that is notif ied whenever the
val ue of the signal (as returned by member f uncti on read) changes and the new value of the signal i s
false or '0' .
virtual bool posedge () const;
Member functi on posedgeshall return the value true i f and onl y if the val ue of the si gnal changed i n
the update phase of the i mmediatel y precedi ng del ta cycle and at the current simulation time, and the
new val ue of the si gnal is true or ' 1'.
virtual bool negedge() const;
Member functi on negedge shall return the val ue true if and onl y i f the value of the si gnal changed
in the update phase of the immediatel y preceding del ta cycl e and at the current si mulati on time, and
the new value of the si gnal i s false or ' 0'.
Exampl e:
sc_signal <bool > cl k;
...
void thread_process()
{
for (;;)
{
if (clk.posedge())
wait(clk.negedge_event());
...
}
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


147
Copyright 2012 IEEE. All rights reserved.
6.6 sc_buffer
6.6.1 Description
Cl ass sc_buffer i s a predefi ned primi ti ve channel deri ved f rom class sc_signal. Cl ass sc_buffer di ff ers f rom
class sc_signal i n that a value-changed event is notif ied whenever the buff er is wri tten rather than only when
the val ue of the signal is changed. A buffer is an object of the class sc_buffer.
6.6.2 Class definition
namespace sc_core {
templ ate <cl ass T, sc_writer_pol icy WRI TER_POLICY>
class sc_buffer
: publi c sc_signal<T,WRITER_POLICY>
{
publ ic:
sc_buffer ();
expl icit sc_buffer( const char* );
virtual void wr ite( const T& );
sc_buff er<T,WRI TER_POLICY>& oper ator = ( const T& );
sc_buff er<T,WRI TER_POLICY>& oper ator = ( const sc_si gnal<T,WRITER_POLI CY>& );
sc_buff er<T,WRI TER_POLICY>& oper ator = ( const sc_buf fer<T,WRI TER_POLI CY>& );
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_buffer ( const sc_buf fer<T,WRI TER_POLI CY>& );
} ;
} // namespace sc_core
6.6.3 Constructors
sc_buffer();
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_signal ( sc_gen_uni que_name( "buf fer" ) )
expl icit sc_buffer ( const char* name_ );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_signal ( name_ )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


148
Copyright 2012 IEEE. All rights reserved.
6.6.4 Member functions
virtual void wr ite( const T& );
Member f unction wr ite shal l modi fy the value of the buf fer such that the buff er appears to have the
new val ue (as returned by member function read) i n the next delta cycle but not bef ore then. Thi s
shal l be accompli shed usi ng the update request mechani sm of the primitive channel . The new value
is passed as an argument to member functi on wr ite.
oper ator =
The behavi or of oper ator = shall be equi val ent to the foll owing def initions:
sc_buff er<T,WRI TER_POLICY>& oper ator = ( const T& arg ) { write( arg ); return * thi s; }
sc_buff er<T,WRI TER_POLICY>&
oper ator = ( const sc_si gnal <T,WRITER_POLI CY>& arg ) { write( arg.read() ); return * this; }
sc_buff er<T,WRI TER_POLICY>&
oper ator = ( const sc_buf fer<T,WRITER_POLI CY>& arg ) { wri te( arg.read() ); return * this; }
virtual void update();
Member f unction update of cl ass sc_signal shal l be overri dden by the i mplementati on i n cl ass
sc_buffer to i mplement the updating of the buff er value that occurs as a resul t of the buf fer bei ng
written. Member f uncti on update shal l modi fy the current val ue of the buff er such that it gets the
new value (as passed as an argument to member f uncti on wr ite) and shall cause the value-changed
event to be notif ied i n the immedi atel y foll owing delta notif ication phase, regardless of whether the
val ue of the buf fer has changed (see 6.4.4 and 6.4.8). (Thi s is in contrast to member function update
of the base class sc_signal, which onl y causes the val ue-changed event to be noti fi ed if the new
val ue i s dif ferent from the old val ue.)
I n other words, suppose the current value of the buf fer is V, and member functi on wr ite i s cal led
wi th argument value V. Functi on wr ite wil l store the new value V (in some impl ementation-defi ned
storage area disti nct f rom the current value of the buff er) and will cal l request_update. Member
f uncti on update wil l be cal led back duri ng the update phase and wi ll set the current val ue of the
buff er to the new val ue V. The current val ue of the buff er wi ll not change, because the ol d value i s
equal to the new val ue but the value-changed event wil l be noti fi ed nonethel ess.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_buffer" .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


149
Copyright 2012 IEEE. All rights reserved.
Exampl e:
SC_MODULE(M)
{
sc_buff er<int> buf ;
SC_CTOR(M)
{
SC_THREAD(wri ter);
SC_METHOD(reader);
sensitive << buf ;
}
void wri ter()
{
buf.write(1);
wait(SC_ZERO_TI ME);
buf.write(1);
}
void reader()
{ // Executed duri ng i ni ti al izati on and then twice more with buf = 0, 1, 1
std::cout << buf << std::endl ;
}
} ;
6.7 sc_clock
6.7.1 Description
Cl ass sc_clock is a predefi ned pri mi tive channel deri ved f rom the class sc_signal and intended to model the
behavior of a digital cl ock si gnal. A cl ock is an obj ect of the class sc_clock. The val ue and events associ ated
wi th the cl ock are accessed through the interface sc_signal_in_if<bool>.
6.7.2 Class definition
namespace sc_core {
class sc_clock
: publi c sc_signal<bool>
{
publ ic:
sc_clock();
expl icit sc_clock( const char* name_ );
sc_clock( const char* name_,
const sc_time& peri od_,
doubl e duty_cycl e_ = 0.5,
const sc_time& start_ti me_ = SC_ZERO_TI ME,
bool posedge_fi rst_ = true );
sc_clock( const char* name_,
doubl e peri od_v_,
sc_time_uni t peri od_tu_,
doubl e duty_cycl e_ = 0.5 );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


150
Copyright 2012 IEEE. All rights reserved.
sc_clock( const char* name_,
doubl e peri od_v_,
sc_time_uni t peri od_tu_,
doubl e duty_cycl e_,
doubl e start_ti me_v_,
sc_ti me_uni t start_time_tu_,
bool posedge_fi rst_ = true );
virtual ~sc_clock();
virtual void wr ite( const bool & );
const sc_time& period() const;
doubl e duty_cycle() const;
const sc_time& star t_time() const;
bool posedge_fir st() const;
virtual const char* kind() const;
protected:
virtual void before_end_of_elaboration();
pri vate:
// Di sabl ed
sc_clock( const sc_cl ock& );
sc_clock& oper ator = ( const sc_cl ock& );
} ;
typedef sc_in<bool > sc_in_clk ;
} // namespace sc_core
6.7.3 Characteristic properties
A clock i s characteri zed by the fol lowing properti es:
a) Peri odThe time interval between two consecutive transitions from value false to value true,
which shall be equal to the ti me interval between two consecutive transitions from val ue true to
val ue false. The peri od shal l be greater than zero. The def aul t peri od i s 1 nanosecond.
b) Duty cycl eThe proportion of the period during which the clock has the value true. The duty cycle
shal l li e between the limits 0.0 and 1.0, excl usive. The default duty cycl e i s 0.5.
c) Star t ti meThe absolute time of the first transition of the value of the clock (false to true or true to
false). The def aul t start ti me i s zero.
d) Posedge_fi r stIf posedge_first is true, the clock i s i nitiali zed to the val ue false, and changes from
false to true at the start time. If posedge_fi rst is false, the cl ock i s ini ti al ized to the val ue true, and
changes f rom true to false at the start time. The defaul t value of posedge_f irst i s true.
NOTEA clock does not have a stop time but wil l stop i n any case when f uncti on sc_stop i s cal l ed.
6.7.4 Constructors
The constructors shall set the characteri stic properties of the cl ock as def ined by the constructor arguments.
Any characteristi c property not defi ned by the constructor arguments shal l take a default val ue as def ined i n
6.7.3.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


151
Copyright 2012 IEEE. All rights reserved.
The default constructor shall call the base class constructor f rom i ts initiali zer li st as foll ows:
sc_signal ( sc_gen_uni que_name( "cl ock" ) )
6.7.5 write
virtual void wr ite( const bool & );
I t shal l be an error for an appli cati on to call member f unction wr ite. The member function wr ite of
the base cl ass sc_signal is not appl icabl e to cl ocks.
6.7.6 Diagnostic member functions
const sc_time& period() const;
Member f uncti on period shall return the peri od of the clock.
doubl e duty_cycle() const;
Member f uncti on duty_cycle shall return the duty cycle of the clock.
const sc_time& star t_time() const;
Member f uncti on star t_time shall return the start ti me of the cl ock.
bool posedge_fir st() const;
Member f uncti on posedge_fir st shal l return the value of the posedge_fi rst property of the clock.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_clock".
6.7.7 before_end_of_elaboration
virtual void before_end_of_elaboration();
Member functi on before_end_of_elaboration, whi ch i s def ined i n the cl ass sc_pr im_channel,
shal l be overridden by the impl ementation i n the current cl ass wi th a behavior that is
impl ementation-def ined.
NOTE 1An implementation may use befor e_end_of_elabor ation to spawn one or more stati c processes to generate
the cl ock.
NOTE 2If this member function is overridden i n a cl ass deri ved f rom the current cl ass, f uncti on
befor e_end_of_elabor ation as overri dden i n the current cl ass shoul d be cal led expl i ci tl y f rom the overri dden member
f uncti on of the deri ved cl ass i n order to i nvoke the i mpl ementati on-def i ned behavi or.
6.7.8 sc_in_clk
typedef sc_in<bool > sc_in_clk ;
The typedef sc_in_clk i s provided for conveni ence when adding clock inputs to a modul e and f or
backward compatibi li ty wi th earli er versions of SystemC. An appl icati on may use sc_in_clk or
sc_in<bool> interchangeably.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


152
Copyright 2012 IEEE. All rights reserved.
6.8 sc_in
6.8.1 Description
Cl ass sc_in is a speci alized port cl ass f or use wi th si gnals. I t provides functions to access conveni ently
certain member f uncti ons of the channel to whi ch the port is bound. I t may be used to model an input pin on
a modul e.
6.8.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_in
: publi c sc_port<sc_signal _in_if <T>,1>
{
publ ic:
sc_in();
expl icit sc_in( const char* );
virtual ~sc_in();
virtual void bind ( const sc_si gnal _i n_if <T>& );
void oper ator () ( const sc_si gnal _i n_i f<T>& );
virtual void bind ( sc_port<sc_signal_in_if <T>, 1>& );
void oper ator () ( sc_port<sc_signal_in_i f<T>, 1>& );
virtual void bind ( sc_port<sc_signal _inout_if <T>, 1>& );
void oper ator () ( sc_port<sc_signal _inout_if <T>, 1>& );
virtual void end_of_elabor ation();
const T& read() const;
oper ator const T& () const;
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
bool event() const;
sc_event_f inder& value_changed() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_in( const sc_in<T>& );
sc_i n<T>& oper ator = ( const sc_in<T>& );
} ;
templ ate <class T>
inl ine voi d sc_trace( sc_trace_f il e* , const sc_i n<T>&, const std::stri ng& );
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


153
Copyright 2012 IEEE. All rights reserved.
6.8.3 Member functions
The constructors shal l pass their arguments to the corresponding constructor for the base class sc_por t.
The i mplementati on of oper ator () shall achieve i ts eff ect by cal li ng the virtual member f unction bind.
Member function bind shal l call member f unction bind of the base class sc_por t, passing through thei r
parameters as arguments to f unction bind, in order to bind the object of cl ass sc_in to the channel or port
instance passed as an argument.
Member function read and oper ator const T& () shall each cal l member f unction read of the object to
which the port i s bound usi ng oper ator-> of class sc_por t, that i s:
(* this)->read()
Member functi ons default_event, value_changed_event, and event shall each cal l the correspondi ng
member functi on of the object to whi ch the port i s bound usi ng oper ator-> of class sc_por t, for example:
(* this)->event()
Member f uncti on value_changed shall return a reference to class sc_event_finder , where the event f inder
object itself shall be constructed using the member function value_changed_event (see 5.7).
Member f uncti on kind shall return the string " sc_in" .
6.8.4 Function sc_trace
templ ate <class T>
inl ine voi d sc_trace( sc_trace_f il e* , const sc_i n<T>&, const std::stri ng& );
Function sc_trace shal l trace the channel to which the port passed as the second argument i s bound
(see 8.1) by call ing f unction sc_trace with a second argument of type const T& (see 6.4.3). The port
need not have been bound at the point duri ng el aborati on when functi on sc_trace i s cal led. In thi s
case, the impl ementation shal l def er the cal l to trace the signal until af ter the port has been bound
and the identi ty of the signal is known.
6.8.5 end_of_elaboration
virtual void end_of_elabor ation();
Member functi on end_of_elabor ation, which i s defi ned in the class sc_por t, shall be overridden by
the impl ementation in the current class wi th a behavi or that i s i mplementati on-def ined.
NOTE 1An implementation may use end_of_elabor ation to impl ement the def erred cal l to sc_tr ace.
NOTE 2If this member function is overridden in a cl ass deri ved f rom the current cl ass, f uncti on end_of_elabor ation
as overri dden i n the current cl ass should be cal l ed expl i ci tl y f rom the overri dden member f uncti on of the deri ved cl ass in
order to invoke the i mpl ementati on-def i ned behavi or.
6.9 sc_in<bool> and sc_in<sc_dt::sc_logic>
6.9.1 Description
Cl ass sc_in<bool> and sc_in<sc_dt::sc_logic> are speciali zed port classes that provide additi onal member
f uncti ons for two-valued si gnals.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


154
Copyright 2012 IEEE. All rights reserved.
6.9.2 Class definition
namespace sc_core {
templ ate <>
class sc_in<bool>
: publi c sc_port<sc_signal _in_if <bool>,1>
{
publ ic:
sc_in();
expl icit sc_in( const char* );
virtual ~sc_in();
virtual void bind ( const sc_si gnal_i n_i f<bool>& );
void oper ator () ( const sc_si gnal _i n_i f<bool>& );
virtual void bind ( sc_port<sc_signal_in_if <bool >, 1>& );
void oper ator () ( sc_port<sc_signal_in_if <bool >, 1>& );
virtual void bind ( sc_port<sc_signal_inout_if <bool >, 1>& );
void oper ator () ( sc_port<sc_signal_inout_if <bool >, 1>& );
virtual void end_of_elabor ation();
const bool& read() const;
oper ator const bool& () const;
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
const sc_event& posedge_event() const;
const sc_event& negedge_event() const;
bool event() const;
bool posedge() const;
bool negedge() const;
sc_event_f inder& value_changed() const;
sc_event_f inder& pos() const;
sc_event_f inder& neg() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_in( const sc_in<bool >& );
sc_i n<bool>& oper ator = ( const sc_in<bool >& );
} ;
templ ate <>
inl ine voi d sc_trace<bool>( sc_trace_f il e* , const sc_i n<bool >&, const std::stri ng& );
templ ate <>
class sc_in<sc_dt::sc_logic>
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


155
Copyright 2012 IEEE. All rights reserved.
: publi c sc_port<sc_signal _in_if <sc_dt::sc_l ogi c>,1>
{
publ ic:
sc_in();
expl icit sc_in( const char* );
virtual ~sc_in();
virtual void bind ( const sc_si gnal_i n_i f<sc_dt::sc_logic>& );
void oper ator () ( const sc_si gnal _i n_i f<sc_dt::sc_logic>& );
virtual void bind ( sc_port<sc_signal_in_if <sc_dt::sc_l ogi c>, 1>& );
void oper ator () ( sc_port<sc_signal_in_if <sc_dt::sc_l ogi c>, 1>& );
virtual void bind ( sc_port<sc_signal _inout_if <sc_dt::sc_l ogic>, 1>& );
void oper ator () ( sc_port<sc_signal _inout_if <sc_dt::sc_l ogic>, 1>& );
virtual void end_of_elabor ation();
const sc_dt::sc_l ogic& read() const;
oper ator const sc_dt::sc_logic& () const;
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
const sc_event& posedge_event() const;
const sc_event& negedge_event() const;
bool event() const;
bool posedge() const;
bool negedge() const;
sc_event_f inder& value_changed() const;
sc_event_f inder& pos() const;
sc_event_f inder& neg() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_in( const sc_in<sc_dt::sc_l ogi c>& );
sc_in<sc_dt::sc_logic>& oper ator = ( const sc_in<sc_dt::sc_l ogi c>& );
} ;
templ ate <>
inl ine voi d
sc_trace<sc_dt::sc_logic>( sc_trace_f il e* , const sc_i n<sc_dt::sc_logic>&, const std::string& );
} // namespace sc_core
6.9.3 Member functions
The f ollowi ng l ist i s i ncomplete. For the remaini ng member f uncti ons and for the f uncti on sc_trace, refer to
the def ini ti ons of the member functions f or class sc_in (see 6.8.3).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


156
Copyright 2012 IEEE. All rights reserved.
Member functi ons posedge_event, negedge_event, posedge, and negedge shall each cal l the correspondi ng
member functi on of the object to whi ch the port i s bound usi ng oper ator-> of class sc_por t, for example:
(* this)->negedge()
Member f unctions pos and neg shal l return a reference to cl ass sc_event_finder, where the event f inder
object itsel f shal l be constructed using the member f uncti on posedge_event or negedge_event, respecti vel y
(see 5.7).
6.10 sc_inout
6.10.1 Description
Cl ass sc_inout is a speci al ized port cl ass for use with signal s. I t provi des functions to access conveni entl y
certai n member f unctions of the channel to whi ch the port i s bound. I t may be used to model an output pin or
a bi directi onal pi n on a modul e.
6.10.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_inout
: publi c sc_port<sc_signal _inout_if <T>,1>
{
publ ic:
sc_inout();
expl icit sc_inout( const char* );
virtual ~sc_inout();
void initialize( const T& );
void initialize( const sc_si gnal _i n_i f<T>& );
virtual void end_of_elabor ation();
const T& read() const;
oper ator const T& () const;
void wr ite( const T& );
sc_i nout<T>& oper ator = ( const T& );
sc_i nout<T>& oper ator = ( const sc_si gnal _i n_i f<T>& );
sc_i nout<T>& oper ator = ( const sc_port< sc_signal_in_if <T>, 1>& );
sc_i nout<T>& oper ator = ( const sc_port< sc_signal_inout_if <T>, 1>& );
sc_i nout<T>& oper ator = ( const sc_inout<T>& );
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
bool event() const;
sc_event_f inder& value_changed() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


157
Copyright 2012 IEEE. All rights reserved.
sc_inout( const sc_inout<T>& );
} ;
templ ate <class T>
inl ine voi d sc_trace( sc_trace_f il e* , const sc_i nout<T>& , const std::stri ng& );
} // namespace sc_core
6.10.3 Member functions
The constructors shal l pass their arguments to the corresponding constructor for the base class sc_por t.
Member function read and oper ator const T& () shall each cal l member f unction read of the object to
which the port i s bound usi ng oper ator-> of class sc_por t, that i s:
(* this)->read()
Member f unction wr ite and oper ator = shal l each call the member function wr ite of the object to which the
port i s bound usi ng oper ator-> of class sc_por t, cal ling member functi on read to get the value of the
parameter, where the parameter is an i nterf ace or a port, for example:
sc_inout<T>& operator= ( const sc_i nout<T>& port_ )
{ (* this)->write( port_->read() ); return * this; }
Member f uncti on wr ite shall not be cal led during el aboration bef ore the port has been bound (see 6.10.4).
Member functi ons default_event, value_changed_event, and event shall each cal l the correspondi ng
member functi on of the object to whi ch the port i s bound usi ng oper ator-> of class sc_por t, for example:
(* this)->event()
Member f uncti on value_changed shall return a reference to class sc_event_finder , where the event f inder
object itself shall be constructed using the member function value_changed_event (see 5.7).
Member f uncti on kind shall return the string " sc_inout" .
6.10.4 initialize
Member function initialize shal l set the ini ti al val ue of the si gnal to whi ch the port is bound by call ing
member function wr ite of that signal usi ng the value passed as an argument to member f unction initialize. I f
the actual argument is a channel , the initial value shall be determined by reading the val ue of the channel.
The port need not have been bound at the poi nt during el aboration when member functi on initialize is
cal led. I n this case, the implementati on shal l def er the call to wr ite until af ter the port has been bound and
the identity of the si gnal i s known.
NOTE 1A port of class sc_in wi l l be bound to exactl y one si gnal , but the bi ndi ng may be perf ormed i ndi rectl y through
a port of the parent module.
NOTE 2The purpose of member function initialize i s to al l ow the val ue of a port to be i ni ti al i zed duri ng elaboration
bef ore the port bei ng bound. However, member functi on initializemay be cal l ed duri ng el aborati on or si mul ati on.
6.10.5 Function sc_trace
templ ate <class T>
inl ine voi d sc_trace( sc_trace_f il e* , const sc_i nout<T>& , const std::stri ng& );
Function sc_trace shal l trace the channel to which the port passed as the second argument i s bound
(see 8.1) by cal li ng function sc_trace wi th a second argument of type const T& (see 6.4.3). The
port need not have been bound at the point duri ng elaboration when f uncti on sc_trace is cal led. I n
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


158
Copyright 2012 IEEE. All rights reserved.
thi s case, the i mplementati on shall defer the call to trace the signal unti l af ter the port has been
bound and the identi ty of the si gnal is known.
6.10.6 end_of_elaboration
virtual void end_of_elabor ation();
Member functi on end_of_elabor ation, which i s defi ned in the class sc_por t, shall be overridden by
the impl ementation in the current class wi th a behavi or that i s i mplementati on-def ined.
NOTE 1An implementation may use end_of_elabor ation to i mpl ement the def erred cal l s f or initializeand sc_tr ace.
NOTE 2If this member function is overridden in a cl ass deri ved f rom the current cl ass, f uncti on end_of_elabor ation
as overri dden i n the current cl ass should be cal l ed expl i ci tl y f rom the overri dden member f uncti on of the deri ved cl ass in
order to invoke the i mpl ementati on-def i ned behavi or.
6.10.7 Binding
Because interface sc_signal_inout_if is derived f rom interface sc_signal_in_if, a port of cl ass sc_in of a
chi ld modul e may be bound to a port of cl ass sc_inout of a parent modul e but a port of cl ass sc_inout of a
chi ld module cannot be bound to a port of cl ass sc_in of a parent modul e.
6.11 sc_inout<bool> and sc_inout<sc_dt::sc_logic>
6.11.1 Description
Cl ass sc_inout<bool> and sc_inout<sc_dt::sc_logic> are speciali zed port cl asses that provide addi tional
member functi ons for two-val ued si gnals.
6.11.2 Class definition
namespace sc_core {
templ ate <>
class sc_inout<bool>
: publi c sc_port<sc_signal _inout_if <bool >,1>
{
publ ic:
sc_inout();
expl icit sc_inout( const char* );
virtual ~sc_inout();
void initialize( const bool& );
void initialize( const sc_si gnal _i n_i f<bool>& );
virtual void end_of_elabor ation();
const bool& r ead() const;
oper ator const bool& () const;
void wr ite( const bool& );
sc_inout<bool>& oper ator = ( const bool& );
sc_inout<bool>& oper ator = ( const sc_si gnal_i n_i f<bool>& );
sc_inout<bool>& oper ator = ( const sc_port< sc_signal_in_if <bool >, 1>& );
sc_inout<bool>& oper ator = ( const sc_port< sc_signal_inout_if <bool >, 1>& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


159
Copyright 2012 IEEE. All rights reserved.
sc_inout<bool>& oper ator = ( const sc_inout<bool >& );
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
const sc_event& posedge_event() const;
const sc_event& negedge_event() const;
bool event() const;
bool posedge() const;
bool negedge() const;
sc_event_f inder& value_changed() const;
sc_event_f inder& pos() const;
sc_event_f inder& neg() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_inout( const sc_inout<bool>& );
} ;
templ ate <>
inl ine voi d sc_trace<bool>( sc_trace_f il e* , const sc_i nout<bool >&, const std::stri ng& );
templ ate <>
class sc_inout<sc_dt::sc_logic>
: publi c sc_port<sc_signal _inout_if <sc_dt::sc_l ogi c>,1>
{
publ ic:
sc_inout();
expl icit sc_inout( const char* );
virtual ~sc_inout();
void initialize( const sc_dt::sc_logic& );
void initialize( const sc_si gnal _i n_i f<sc_dt::sc_logic>& );
virtual void end_of_elabor ation();
const sc_dt::sc_l ogic& r ead() const;
oper ator const sc_dt::sc_logic& () const;
void wr ite( const sc_dt::sc_logic& );
sc_inout<sc_dt::sc_logic>& oper ator = ( const sc_dt::sc_logic& );
sc_inout<sc_dt::sc_logic>& oper ator = ( const sc_si gnal_i n_i f<sc_dt::sc_logic>& );
sc_inout<sc_dt::sc_logic>& oper ator = ( const sc_port< sc_signal_in_if <sc_dt::sc_l ogi c>, 1>& );
sc_inout<sc_dt::sc_logic>& oper ator = ( const sc_port< sc_si gnal _i nout_if <sc_dt::sc_logic>, 1>&);
sc_inout<sc_dt::sc_logic>& oper ator = ( const sc_inout<sc_dt::sc_logic>& );
const sc_event& default_event() const;
const sc_event& value_changed_event() const;
const sc_event& posedge_event() const;
const sc_event& negedge_event() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


160
Copyright 2012 IEEE. All rights reserved.
bool event() const;
bool posedge() const;
bool negedge() const;
sc_event_f inder& value_changed() const;
sc_event_f inder& pos() const;
sc_event_f inder& neg() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_inout( const sc_inout<sc_dt::sc_l ogi c>& );
} ;
templ ate <>
inl ine voi d
sc_trace<sc_dt::sc_logic>( sc_trace_f il e* , const sc_inout<sc_dt::sc_l ogic>&, const std::stri ng& );
} // namespace sc_core
6.11.3 Member functions
The f ollowi ng l ist i s i ncomplete. For the remaini ng member f uncti ons and for the f uncti on sc_trace, refer to
the def ini ti ons of the member functions f or class sc_inout.
Member functi ons posedge_event, negedge_event, posedge, and negedge shall each cal l the correspondi ng
member functi on of the object to whi ch the port i s bound usi ng oper ator-> of class sc_por t, for example:
(* this)->negedge()
Member f unctions pos and neg shal l return a reference to cl ass sc_event_finder, where the event f inder
object itsel f shal l be constructed using the member f uncti on posedge_event or negedge_event, respecti vel y
(see 5.7).
Member f uncti on kind shall return the string " sc_inout" .
6.12 sc_out
6.12.1 Description
Cl ass sc_out is derived from cl ass sc_inout and is identical to class sc_inout except for di ff erences i nherent
in it bei ng a derived class, f or example, constructors and assignment operators. The purpose of havi ng both
classes is to al low users to express their i ntent, that is, sc_out f or output pi ns and sc_inout f or bi directi onal
pins.
6.12.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_out
: publi c sc_i nout<T>
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


161
Copyright 2012 IEEE. All rights reserved.
{
publ ic:
sc_out();
expl icit sc_out( const char* );
virtual ~sc_out();
sc_out<T>& oper ator = ( const T& );
sc_out<T>& oper ator = ( const sc_si gnal _i n_i f<T>& );
sc_out<T>& oper ator = ( const sc_port< sc_signal_in_i f<T>, 1>& );
sc_out<T>& oper ator = ( const sc_port< sc_signal _inout_if <T>, 1>& );
sc_out<T>& oper ator = ( const sc_out<T>& );
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_out( const sc_out<T>& );
} ;
} // namespace sc_core
6.12.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_inout<T>.
The behavi or of the assi gnment operators shal l be i dentical to that of class sc_inout but wi th the class name
sc_out substi tuted in place of the class name sc_inout wherever appropri ate.
Member f uncti on kind shall return the string " sc_out" .
6.13 sc_signal_resolved
6.13.1 Description
Cl ass sc_signal_resolved i s a predef ined pri mitive channel deri ved from class sc_signal. A resol ved si gnal
is an obj ect of class sc_signal_resolved or cl ass sc_signal_r v. Class sc_signal_resolved di ff ers f rom class
sc_signal in that a resol ved signal may be wri tten by mul ti ple processes, confli cti ng val ues bei ng resolved
wi thin the channel .
6.13.2 Class definition
namespace sc_core {
class sc_signal_r esolved
: publi c sc_signal<sc_dt::sc_logic,SC_MANY_WRITERS>
{
publ ic:
sc_signal_r esolved();
expl icit sc_signal_r esolved( const char* );
virtual ~sc_signal_r esolved();
virtual void r egister_port( sc_port_base&, const char* );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


162
Copyright 2012 IEEE. All rights reserved.
virtual void wr ite( const sc_dt::sc_l ogi c& );
sc_signal _resol ved& oper ator = ( const sc_dt::sc_logic& );
sc_signal _resol ved& oper ator = ( const sc_si gnal _resol ved& );
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_signal_r esolved( const sc_si gnal _resolved& );
} ;
} // namespace sc_core
6.13.3 Constructors
sc_signal_resolved();
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_signal ( sc_gen_uni que_name( "si gnal_resolved" ) )
expl icit sc_signal_resolved( const char* name_ );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_signal ( name_ )
6.13.4 Resolution semantics
A resolved si gnal i s written by call ing member f uncti on wr ite or oper ator = of the given si gnal obj ect. Li ke
class sc_signal, oper ator = shall cal l member functi on wr ite.
Each resolved si gnal shal l mai ntai n a l i st of wri tten val ues contai ni ng one val ue f or each distinct process
instance that writes to the resol ved signal obj ect. Thi s l ist shal l store the value most recentl y written to the
resolved signal object by each such process instance.
I f and only i f the wri tten value i s diff erent from the previ ous written value or this i s the f irst occasion on
which the particular process i nstance has wri tten to the particular signal object, the member f uncti on wr ite
shall then call the member function request_update.
Duri ng the update phase, member function update shal l f irst use the l ist of wri tten values to calculate a
single r esol ved val ue for the resol ved si gnal , and then perf orm update semanti cs si mi lar to class sc_signal
but usi ng the resolved value j ust cal cul ated.
A value shall be added to the l ist of wri tten values on the f irst occasi on that each particul ar process instance
writes to the resol ved si gnal object. Val ues shal l not be removed f rom the l ist of written values. Bef ore the
f irst occasion on whi ch a gi ven process i nstance writes to a given resol ved si gnal, that process instance shall
not contri bute to the calcul ati on of the resol ved val ue f or that si gnal.
The resolved value shall be cal cul ated f rom the l ist of wri tten val ues usi ng the fol lowi ng algori thm:
1) Take a copy of the li st.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


163
Copyright 2012 IEEE. All rights reserved.
2) Take any two val ues f rom the copy of the l ist and repl ace them with one value according to the
truth table shown in Tabl e 3.
3) Repeat step 2) unti l only a single val ue remains. This is the resol ved val ue.
Before the f irst occasion on whi ch a given process i nstance writes to a gi ven resolved signal , the val ue
written by that process instance i s ef fecti vel y 'Z' in terms of i ts ef fect on the resoluti on cal cul ation. On the
other hand, the def ault i nitial val ue for a resol ved si gnal (as would be returned by member f unction read
bef ore the fi rst wr ite) is 'X '. Thus, it i s strongl y recommended that each process i nstance that writes to a
given resolved si gnal perf orm a write to that si gnal at time zero.
NOTE 1The order in which values are passed to the function def i ned by the truth table i n Tabl e 3 does not af f ect the
resul t of the cal cul ati on.
NOTE 2The calculation of the resolved value is performed usi ng the val ue most recentl y wri tten by each and every
process that wri tes to that parti cul ar si gnal obj ect, regardl ess of whether the most recent wri te occurred i n the current
del ta cycl e, i n a previ ous del ta cycl e, or at an earl ier ti me.
NOTE 3These same resolution semanti cs appl y, whether the resolved si gnal i s accessed di rectl y by a process or i s
accessed i ndi rectl y through a port bound to the resol ved si gnal .
6.13.5 Member functions
Member function register _por t of class sc_signal shall be overri dden i n class sc_signal_resolved, such that
the error check for mul ti ple output ports perf ormed by sc_signal::r egister _port is di sabled for channel
objects of cl ass sc_signal_resolved.
Member function wr ite, oper ator =, and member f uncti on update shal l have the same behavi or as the
correspondi ng members of cl ass sc_signal, except where the behavior diff ers f or multiple writers as defi ned
in 6.13.4.
Member f uncti on kind shall return the string " sc_signal_resolved" .
Exampl e:
SC_MODULE(M)
{
sc_signal _resol ved si g;
SC_CTOR(M)
{
SC_THREAD(T1);
SC_THREAD(T2);
SC_THREAD(T3);
}
Table 3Resolution table for sc_signal_resolved
' 0' '1' ' Z' 'X'
' 0' '0' 'X' '0' 'X'
' 1' 'X' '1' '1' 'X'
'Z' '0' '1' 'Z' 'X'
'X' 'X' 'X' 'X' ' X'
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


164
Copyright 2012 IEEE. All rights reserved.
voi d T1()
{ // Ti me=0 ns, no written values si g=X
wait(10, SC_NS);
sig = sc_dt::SC_LOGIC_0; // Time=10 ns, written values=0 sig=0
wait(20, SC_NS);
sig = sc_dt::SC_LOGIC_Z; // Time=30 ns, written values=Z,Z sig=Z
}
voi d T2()
{
wait(20, SC_NS);
sig = sc_dt::SC_LOGIC_Z; // Time=20 ns, written values=0,Z sig=0
wait(30, SC_NS);
sig = sc_dt::SC_LOGIC_0; // Time=50 ns, written values=Z,0,1 sig=X
}
voi d T3()
{
wait(40, SC_NS);
sig = sc_dt::SC_LOGIC_1; // Time=40 ns, written values=Z,Z,1 sig=1
}
} ;
6.14 sc_in_resolved
6.14.1 Description
Cl ass sc_in_r esolved is a speciali zed port class for use wi th resol ved si gnals. It i s simi lar i n behavior to port
class sc_in<sc_dt::sc_logic> f rom whi ch i t i s derived. The onl y dif ference is that a port of class
sc_in_r esolved shall be bound to a channel of class sc_signal_resolved, whereas a port of class
sc_in<sc_dt::sc_logic> may be bound to a channel of class
sc_signal<sc_dt::sc_logic,W RI TER_POLI CY > or class sc_signal_resolved.
6.14.2 Class definition
namespace sc_core {
class sc_in_r esolved
: publi c sc_i n<sc_dt::sc_logic>
{
publ ic:
sc_in_r esolved();
expl icit sc_in_r esolved( const char* );
virtual ~sc_in_r esolved();
virtual void end_of_elabor ation();
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_in_r esolved( const sc_in_resolved& );
sc_i n_resolved& operator = (const sc_in_resol ved& );
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


165
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_core
6.14.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_in<sc_dt::sc_logic>.
Member function end_of_elaboration shal l perform an error check. I t is an error i f the port i s not bound to
a channel of cl ass sc_signal_resolved.
Member f uncti on kind shall return the string " sc_in_resolved" .
NOTEAs always, the port may be bound indirectl y through a port of a parent modul e.
6.15 sc_inout_resolved
6.15.1 Description
Cl ass sc_inout_r esolved i s a speci al ized port cl ass for use wi th resolved signal s. I t is si mi lar in behavior to
port class sc_inout<sc_dt::sc_logic> from which i t is derived. The only dif ference is that a port of cl ass
sc_inout_r esolved shall be bound to a channel of cl ass sc_signal_resolved, whereas a port of class
sc_inout<sc_dt::sc_logic> may be bound to a channel of cl ass
sc_signal<sc_dt::sc_logic,W RI TER_POLI CY > or class sc_signal_resolved.
6.15.2 Class definition
namespace sc_core {
class sc_inout_r esolved
: publi c sc_i nout<sc_dt::sc_logi c>
{
publ ic:
sc_inout_r esolved();
expl icit sc_inout_r esolved( const char* );
virtual ~sc_inout_resolved();
virtual void end_of_elabor ation();
sc_inout_resolved& oper ator = ( const sc_dt::sc_logic& );
sc_inout_resolved& oper ator = ( const sc_si gnal_i n_i f<sc_dt::sc_logic>& );
sc_inout_resolved& oper ator = ( const sc_port<sc_signal_in_if <sc_dt::sc_l ogic>, 1>& );
sc_inout_resolved& oper ator = ( const sc_port<sc_signal_inout_i f<sc_dt::sc_logic>, 1>& );
sc_inout_resolved& oper ator = ( const sc_inout_resol ved& );
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_inout_r esolved( const sc_inout_resol ved& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


166
Copyright 2012 IEEE. All rights reserved.
6.15.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_inout<sc_dt::sc_logic>.
Member function end_of_elaboration shal l perform an error check. I t is an error i f the port i s not bound to
a channel of cl ass sc_signal_resolved.
The behavi or of the assi gnment operators shal l be identical to that of cl ass sc_inout<sc_dt::sc_logic> but
wi th the cl ass name sc_inout_r esolved substi tuted in place of the class name sc_inout<sc_dt::sc_logic>
wherever appropriate.
Member f uncti on kind shall return the string " sc_inout_r esolved" .
NOTEAs always, the port may be bound indirectl y through a port of a parent modul e.
6.16 sc_out_resolved
6.16.1 Description
Cl ass sc_out_resolved i s derived f rom cl ass sc_inout_r esolved, and i t is identi cal to cl ass
sc_inout_r esolved except for dif ferences i nherent in it bei ng a derived cl ass, f or exampl e, constructors and
assignment operators. The purpose of havi ng both cl asses is to all ow users to express thei r intent, that is,
sc_out_r esolved f or output pi ns connected to resolved si gnals and sc_inout_r esolved f or bidi recti onal pi ns
connected to resol ved si gnal s.
6.16.2 Class definition
namespace sc_core {
class sc_out_r esolved
: publi c sc_i nout_resol ved
{
publ ic:
sc_out_r esolved();
expl icit sc_out_r esolved( const char* );
virtual ~sc_out_r esolved();
sc_out_resolved& oper ator = ( const sc_dt::sc_l ogi c& );
sc_out_resolved& oper ator = ( const sc_si gnal _i n_i f<sc_dt::sc_logic>& );
sc_out_resolved& oper ator = ( const sc_port<sc_si gnal_i n_i f<sc_dt::sc_logic>, 1>& );
sc_out_resolved& oper ator = ( const sc_port<sc_signal_i nout_i f<sc_dt::sc_l ogi c>, 1>& );
sc_out_resolved& oper ator = ( const sc_out_resol ved& );
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_out_r esolved( const sc_out_resol ved& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


167
Copyright 2012 IEEE. All rights reserved.
6.16.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_inout_r esolved.
The behavior of the assignment operators shall be identical to that of class sc_inout_r esolved but with the
class name sc_out_resolved substituted i n place of the cl ass name sc_inout_r esolved wherever appropri ate.
Member f uncti on kind shall return the string " sc_out_resolved" .
6.17 sc_signal_rv
6.17.1 Description
Cl ass sc_signal_r v is a predefi ned pri mitive channel derived f rom class sc_signal. Class sc_signal_r v is
simi lar to cl ass sc_signal_resolved. The di ff erence is that the argument to the base class templ ate sc_signal
is type sc_dt::sc_lv<W > instead of type sc_dt::sc_logic.
6.17.2 Class definition
namespace sc_core {
templ ate <i nt W>
class sc_signal_r v
: publi c sc_si gnal<sc_dt::sc_lv<W>,SC_MANY_WRI TERS>
{
publ ic:
sc_signal_r v();
expl icit sc_signal_r v( const char* );
virtual ~sc_signal_r v();
virtual void r egister_port( sc_port_base&, const char* );
virtual void wr ite( const sc_dt::sc_lv<W>& );
sc_signal_rv<W>& oper ator = ( const sc_dt::sc_lv<W>& );
sc_signal_rv<W>& oper ator = ( const sc_si gnal _rv<W>& );
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_signal_r v( const sc_si gnal _rv<W>& );
} ;
} // namespace sc_core
6.17.3 Semantics and member functions
The semantics of cl ass sc_signal_r v shall be i denti cal to the semantics of class sc_signal_resolved except
f or dif ferences due to the fact that the val ue to be resol ved is of type sc_dt::sc_lv (see 6.13.4).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


168
Copyright 2012 IEEE. All rights reserved.
The val ue shall be propagated through the resolved signal as an atomi c val ue; that i s, an event shal l be
noti fi ed, and the entire val ue of the vector shal l be resolved and updated whenever any bi t of the vector
written by any process changes.
The l i st of wr i tten val ues shall contai n values of type sc_dt::sc_lv, and each value of type sc_dt::sc_lv shall
be treated atomicall y f or the purpose of buildi ng and updating the li st.
I f and onl y if the written val ue dif fers from the previous wri tten val ue (i n one or more bi t posi tions) or this i s
the f irst occasi on on which the particular process has wri tten to the parti cul ar signal object, the member
functi on wr ite shall then call the member function request_update.
The resolved val ue shall be calculated f or the enti re vector by applyi ng the rule descri bed in 6.13.4 to each
bit position within the vector i n turn.
The default constructor shall call the base class constructor f rom i ts initiali zer li st as foll ows:
sc_signal ( sc_gen_uni que_name( "si gnal_rv" ) )
Member f uncti on kind shall return the string " sc_signal_rv" .
6.18 sc_in_rv
6.18.1 Description
Cl ass sc_in_r v i s a special ized port class f or use with resolved signal s. I t is si mi lar i n behavi or to port cl ass
sc_in<sc_dt::sc_lv<W>> from which it is derived. The onl y di ff erence is that a port of cl ass sc_in_r v shal l
be bound to a channel of class sc_signal_r v, whereas a port of cl ass sc_in<sc_dt::sc_lv<W>> may be
bound to a channel of cl ass sc_signal<sc_dt::sc_lv<W >,W RI TER_POLI CY > or class sc_signal_r v.
6.18.2 Class definition
namespace sc_core {
templ ate <i nt W>
class sc_in_r v
: publi c sc_i n<sc_dt::sc_lv<W>>
{
publ ic:
sc_in_r v();
expl icit sc_in_r v( const char* );
virtual ~sc_in_r v();
virtual void end_of_elabor ation();
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_in_r v( const sc_in_rv<W>& );
sc_in_rv<W>& oper ator = ( const sc_i n_rv<W>& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


169
Copyright 2012 IEEE. All rights reserved.
6.18.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_in<sc_dt::sc_lv<W>>.
Member function end_of_elaboration shal l perform an error check. I t is an error i f the port i s not bound to
a channel of cl ass sc_signal_r v.
Member f uncti on kind shall return the string " sc_in_r v".
NOTEAs always, the port may be bound indirectl y through a port of a parent modul e.
6.19 sc_inout_rv
6.19.1 Description
Cl ass sc_inout_rv is a speciali zed port cl ass for use wi th resolved signals. It is si mi lar i n behavi or to port
class sc_inout<sc_dt::sc_lv<W>> f rom whi ch i t i s deri ved. The onl y di ff erence is that a port of cl ass
sc_inout_r v shal l be bound to a channel of cl ass sc_signal_r v, whereas a port of cl ass
sc_inout<sc_dt::sc_lv<W>> may be bound to a channel of class
sc_signal<sc_dt::sc_lv<W >,W RI TER_POLI CY > or class sc_signal_r v.
6.19.2 Class definition
namespace sc_core {
templ ate <i nt W>
class sc_inout_r v
: publi c sc_i nout<sc_dt::sc_l v<W>>
{
publ ic:
sc_inout_r v();
expl icit sc_inout_r v( const char* );
virtual ~sc_inout_rv();
sc_inout_rv<W>& oper ator = ( const sc_dt::sc_lv<W>& );
sc_inout_rv<W>& oper ator = ( const sc_si gnal_i n_i f<sc_dt::sc_lv<W>>& );
sc_inout_rv<W>& oper ator = ( const sc_port<sc_signal_i n_i f<sc_dt::sc_l v<W>>, 1>& );
sc_inout_rv<W>& oper ator = ( const sc_port<sc_signal_i nout_if <sc_dt::sc_lv<W>>, 1>& );
sc_inout_rv<W>& oper ator = ( const sc_inout_rv<W>& );
virtual void end_of_elabor ation();
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_inout_r v( const sc_inout_rv<W>& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


170
Copyright 2012 IEEE. All rights reserved.
6.19.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_inout<sc_dt::sc_lv<W>>.
Member function end_of_elaboration shal l perform an error check. I t is an error i f the port i s not bound to
a channel of cl ass sc_signal_r v.
The behavior of the assi gnment operators shall be identical to that of class sc_inout<sc_dt::sc_lv<W >> but
wi th the class name sc_inout_r v substituted i n place of the cl ass name sc_inout<sc_dt::sc_lv<W>>
wherever appropriate.
Member f uncti on kind shall return the string " sc_inout_r v" .
NOTEThe port may be bound indirectly through a port of a parent module.
6.20 sc_out_rv
6.20.1 Description
Cl ass sc_out_r v i s derived f rom cl ass sc_inout_r v, and i t i s identi cal to cl ass sc_inout_r v except f or
dif ferences inherent i n it being a derived cl ass, for exampl e, constructors and assignment operators. The
purpose of having both classes i s to al low users to express their i ntent, that is, sc_out_r v for output pins
connected to resol ved vectors and sc_inout_rv for bi directi onal pi ns connected to resolved vectors.
6.20.2 Class definition
namespace sc_core {
templ ate <i nt W>
class sc_out_r v
: publi c sc_i nout_rv<W>
{
publ ic:
sc_out_r v();
expl icit sc_out_r v( const char* );
virtual ~sc_out_r v();
sc_out_rv<W>& operator = ( const sc_dt::sc_lv<W>& );
sc_out_rv<W>& oper ator = ( const sc_si gnal _i n_i f<sc_dt::sc_lv<W>>& );
sc_out_rv<W>& oper ator = ( const sc_port<sc_si gnal_i n_i f<sc_dt::sc_lv<W>>, 1>& );
sc_out_rv<W>& oper ator = ( const sc_port<sc_si gnal_i nout_i f<sc_dt::sc_lv<W>>, 1>& );
sc_out_rv<W>& oper ator = ( const sc_out_rv<W>& );
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_out_r v( const sc_out_rv<W>& );
} ;
} // namespace sc_core
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


171
Copyright 2012 IEEE. All rights reserved.
6.20.3 Member functions
The constructors shall pass their arguments to the corresponding constructors for the base cl ass
sc_inout_r v<W >.
The behavi or of the assi gnment operators shal l be i denti cal to that of cl ass sc_inout_r v<W > but with the
class name sc_out_r v<W> substi tuted in place of the class name sc_inout_r v<W > wherever appropri ate.
Member f uncti on kind shall return the string " sc_out_r v" .
6.21 sc_fifo_in_if
6.21.1 Description
Cl ass sc_fifo_in_if i s an interface proper and i s impl emented by the predef ined channel sc_fifo. I nterf ace
sc_fifo_in_if gi ves read access to a f if o channel, and it i s derived from two further interfaces proper,
sc_fifo_nonblocking_in_if and sc_fifo_blocking_in_if.
6.21.2 Class definition
namespace sc_core {
templ ate <cl ass T>
class sc_fifo_nonblocking_in_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual bool nb_read( T& ) = 0;
virtual const sc_event& data_wr itten_event() const = 0;
} ;
templ ate <cl ass T>
class sc_fifo_blocking_in_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual void read( T& ) = 0;
virtual T read() = 0;
} ;
templ ate <class T>
class sc_fifo_in_if : publi c sc_f if o_nonblocki ng_i n_i f<T>, publ ic sc_f if o_blocking_in_if <T>
{
publ ic:
virtual i nt num_available() const = 0;
protected:
sc_fifo_in_if();
pri vate:
// Di sabl ed
sc_fifo_in_if( const sc_fi fo_in_if <T>& );
sc_f if o_i n_i f<T>& oper ator = ( const sc_fi fo_in_if <T>& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


172
Copyright 2012 IEEE. All rights reserved.
} ;
} // namespace sc_core
6.21.3 Member functions
The f oll owing member functions are all pure vi rtual functi ons. The descriptions refer to the expected
def ini ti ons of the functions when overri dden i n a channel that impl ements this i nterf ace. The preci se
semanti cs wi ll be channel -speci fi c.
Member functi ons read and nb_read shall return the val ue least recently wri tten into the fi fo and shal l
remove that val ue f rom the f if o such that i t cannot be read agai n. I f the fi fo i s empty, member functi on read
shall suspend unti l a value has been wri tten to the fi fo, whereas member f unction nb_read shall return
immedi ately. The return val ue of the f unction nb_read shal l indicate whether a value was read.
When call ing member f uncti on void read(T& ) of cl ass sc_fifo_blocking_in_if, the appl icati on shall be
obli ged to ensure that the li fetime of the actual argument extends from the ti me the f unction is call ed to the
ti me the f unction call reaches compl eti on. Moreover, the appli cati on shal l not modif y the value of the actual
argument during that peri od.
Member function data_wr itten_event shal l return a ref erence to an event that is noti fied whenever a val ue
is written i nto the fi fo.
Member f uncti on num_available shall return the number of values currentl y avail able in the fi fo to be read.
6.22 sc_fifo_out_if
6.22.1 Description
Cl ass sc_fifo_out_if is an i nterf ace proper and i s i mplemented by the predef ined channel sc_fifo. I nterface
sc_fifo_out_if gives wri te access to a fi fo channel and is derived from two f urther interfaces proper,
sc_fifo_nonblocking_out_if and sc_fifo_blocking_out_if.
6.22.2 Class definition
namespace sc_core {
templ ate <cl ass T>
class sc_fifo_nonblocking_out_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual bool nb_write( const T& ) = 0;
virtual const sc_event& data_read_event() const = 0;
} ;
templ ate <cl ass T>
class sc_fifo_blocking_out_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual void wr ite( const T& ) = 0;
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


173
Copyright 2012 IEEE. All rights reserved.
templ ate <class T>
class sc_fifo_out_if : publi c sc_f if o_nonblocki ng_out_i f<T>, publ ic sc_f ifo_blocking_out_i f<T>
{
publ ic:
virtual i nt num_fr ee() const = 0;
protected:
sc_fifo_out_if();
pri vate:
// Di sabl ed
sc_fifo_out_if( const sc_fi fo_out_if <T>& );
sc_f if o_out_i f<T>& oper ator = ( const sc_fi fo_out_if <T>& );
} ;
} // namespace sc_core
6.22.3 Member functions
The f oll owing member functions are all pure vi rtual functi ons. The descriptions refer to the expected
def ini ti ons of the functions when overri dden i n a channel that impl ements this i nterf ace. The preci se
semanti cs wi ll be channel -speci fi c.
Member f uncti ons wr ite and nb_write shall wri te the value passed as an argument i nto the f if o. I f the fi fo is
f ul l, member f uncti on wr ite shal l suspend unti l a val ue has been read f rom the fi f o, whereas member
functi on nb_write shal l return i mmediatel y. The return value of the functi on nb_write shal l i ndi cate
whether a val ue was written into an empty slot.
When call ing member functi on void wr ite(const T& ) of class sc_fifo_blocking_out_if, the appli cation
shall be obl iged to ensure that the l if etime of the actual argument extends f rom the time the functi on is cal led
to the time the function cal l reaches completi on, and moreover, the appli cation shall not modi fy the val ue of
the actual argument duri ng that period.
Member f uncti on data_read_event shall return a reference to an event that i s noti fi ed whenever a value i s
read from the f if o.
Member f unction num_fr ee shal l return the number of unoccupied slots i n the fi fo avai lable to accept
written values.
6.23 sc_fifo
6.23.1 Description
Cl ass sc_fifo i s a predef ined pri mitive channel i ntended to model the behavior of a f if o, that is, a fi rst-in-
f irst-out buf fer. In this clause, fi fo refers to an object of cl ass sc_fifo. Each f if o has a number of sl ots f or
stori ng values. The number of slots i s f ixed when the obj ect i s constructed.
6.23.2 Class definition
namespace sc_core {
templ ate <class T>
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


174
Copyright 2012 IEEE. All rights reserved.
class sc_fifo
: publi c sc_f if o_in_if <T>, publi c sc_fif o_out_i f<T>, publ ic sc_pri m_channel
{
publ ic:
expl icit sc_fifo( i nt size_ = 16 );
expl icit sc_fifo( const char* name_, i nt si ze_ = 16);
virtual ~sc_fifo();
virtual void register _por t( sc_port_base&, const char* );
virtual void read( T& );
virtual T read();
virtual bool nb_read( T& );
oper ator T ();
virtual void wr ite( const T& );
virtual bool nb_write( const T& );
sc_f if o<T>& oper ator = ( const T& );
virtual const sc_event& data_wr itten_event() const;
virtual const sc_event& data_read_event() const;
virtual i nt num_available() const;
virtual i nt num_fr ee() const;
virtual void pr int( std::ostream& = std::cout ) const;
virtual void dump( std::ostream& = std::cout ) const;
virtual const char* kind() const;
protected:
virtual void update();
pri vate:
// Di sabl ed
sc_fifo( const sc_fi fo<T>& );
sc_f if o& oper ator = ( const sc_fi fo<T>& );
} ;
templ ate <class T>
inl ine std::ostream& oper ator << ( std::ostream& , const sc_fi fo<T>& );
} // namespace sc_core
6.23.3 Template parameter T
The argument passed to template sc_fifo shall be ei ther a C++ type for which the predefi ned semanti cs for
assignment are adequate (f or exampl e, a fundamental type or a pointer) or a type T that obeys each of the
f ol lowi ng rul es:
a) The f ol lowi ng stream operator shall be defi ned and should copy the state of the obj ect given as the
second argument to the stream given as the fi rst argument. The way in whi ch the state i nf ormation i s
f ormatted is undef ined by this standard. The i mplementati on shal l use this operator i n i mplementi ng
the behavior of the member f unctions pr int and dump.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


175
Copyright 2012 IEEE. All rights reserved.
std::ostream& oper ator << ( std::ostream&, const T& );
b) I f the def aul t assignment semantics are i nadequate to assign the state of the object, the foll owing
assignment operator shoul d be def ined f or the type T. The impl ementation shall use this operator to
copy the val ue being wri tten into a f if o slot or the value being read out of a f if o slot.
const T& oper ator = ( const T& );
c) I f any constructor f or type T exi sts, a def aul t constructor for type T shal l be defi ned.
NOTE 1The assignment operator is not obli ged to assi gn the compl ete state of the obj ect, al though i t shoul d typi cal l y
do so. For exampl e, di agnosti c i nf ormati on may be associ ated wi th an obj ect that i s not to be propagated through the
f i f o.
NOTE 2The SystemC data types proper (sc_dt::sc_int, sc_dt::sc_logic, and so f orth) al l conform to the above rul e
set.
NOTE 3It is legal to pass type sc_module* through a f if o, al though thi s woul d be regarded as an abuse of the modul e
hi erarchy and thus bad practice.
6.23.4 Constructors
expl icit sc_fifo( i nt size_ = 16 );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_pri m_channel ( sc_gen_unique_name( "f if o" ) )
expl icit sc_fifo( const char* name_, i nt si ze_ = 16 );
This constructor shall cal l the base cl ass constructor f rom its ini ti al izer li st as f ol lows:
sc_pri m_channel ( name_ )
Both constructors shal l i nitiali ze the number of sl ots i n the fi fo to the val ue gi ven by the parameter size_.
The number of slots shal l be greater than zero.
6.23.5 register_port
virtual void register _por t( sc_port_base&, const char* );
Member f uncti on register _por t of class sc_interface shall be overri dden in cl ass sc_fifo and shall
perf orm an error check. I t i s an error if more than one port of type sc_fifo_in_if i s bound to a given
f if o, and i t is an error i f more than one port of type sc_fifo_out_if is bound to a gi ven fi fo.
6.23.6 Member functions for reading
virtual void read( T& );
virtual T read();
virtual bool nb_read( T& );
Member functions read and nb_read shal l return the val ue l east recentl y written into the f if o and
shal l remove that val ue from the f i f o such that i t cannot be read again. Mul ti pl e val ues may be read
wi thin a si ngle delta cycle. The order in whi ch val ues are read from the fi fo shall precisely match the
order i n which val ues were written into the f if o. Values written into the fif o duri ng the current delta
cycl e are not avail able f or reading in that del ta cycle but become avail abl e f or reading i n the
immedi ately fol lowi ng del ta cycl e.
The value read from the f if o shal l be returned as the val ue of the member f uncti on or as an argument
passed by reference, as appropriate.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


176
Copyright 2012 IEEE. All rights reserved.
I f the f if o i s empty (that is, no val ues are avai lable for reading), member function read shall suspend
unti l the data-wr i tten event is notif ied. At that poi nt, it shall resume (i n the i mmediatel y f ol lowi ng
eval uation phase) and compl ete the readi ng of the value l east recently wri tten into the f if o bef ore
returning.
I f the f if o i s empty, member f unction nb_read shal l return immedi ately without modif yi ng the state
of the fi fo, without call ing request_update, and with a return value of false. Otherwi se, if a val ue i s
avai lable for reading, the return value of member functi on nb_read shall be true.
oper ator T ();
The behavi or of oper ator T() shall be equival ent to the foll owing def ini ti on:
operator T (){ return read(); }
6.23.7 Member functions for writing
virtual void wr ite( const T& );
virtual bool nb_write( const T& );
Member f unctions wr ite and nb_write shal l write the value passed as an argument into the f if o.
Mul ti pl e values may be written wi thi n a single del ta cycl e. If values are read from the f if o duri ng the
current delta cycle, the empty sl ots in the fi fo so created do not become free f or the purposes of
writing unti l the i mmedi ately fol lowi ng delta cycl e.
I f the fi fo is full (that i s, no f ree slots exist for the purposes of wri ti ng), member f unction wr ite shall
suspend until the data-r ead event is notif ied. At which poi nt, it shall resume (i n the i mmediately
f ol lowi ng evaluati on phase) and complete the writing of the argument val ue into the f if o bef ore
returning.
I f the f if o i s ful l, member f unction nb_write shall return immedi atel y wi thout modif yi ng the state of
the f if o, wi thout call ing request_update, and wi th a return val ue of false. Otherwi se, i f a slot is f ree,
the return value of member f uncti on nb_write shall be true.
oper ator =
The behavi or of oper ator = shall be equi val ent to the foll owing def inition:
sc_f if o<T>& operator= ( const T& a ) { wri te( a ); return * this; }
6.23.8 The update phase
Member f unctions read, nb_read, wr ite, and nb_write shal l complete the act of reading or wri ti ng the fi fo
by call ing member functi on request_update of class sc_pr im_channel.
virtual void update();
Member function update of class sc_pr im_channel shal l be overridden in class sc_fifo to update
the number of values available f or readi ng and the number of f ree sl ots f or writing and shall cause
the data-wr i tten event or the data-r ead event to be notif ied i n the immedi ately f ollowi ng del ta
noti ficati on phase as necessary.
NOTEIf a fifo is empty and member functions wr ite and r ead are both cal led (f rom the same process or f rom
two di f f erent processes) duri ng the eval uation phase of the same del ta cycl e, the wri te wi l l compl ete i n that
del ta cycl e, but the read wil l suspend because the f i f o i s empty. The number of val ues avai l abl e f or readi ng wi l l
be i ncremented to one duri ng the update phase, and the read wi l l compl ete i n the f ol l owi ng del ta cycl e,
returni ng the value j ust wri tten.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


177
Copyright 2012 IEEE. All rights reserved.
6.23.9 Member functions for events
virtual const sc_event& data_wr itten_event() const;
Member function data_wr itten_event shall return a ref erence to an event, the data-wri tten event,
that i s noti fi ed in the del ta notif icati on phase that occurs at the end of the del ta cycle in which a
val ue i s written into the fi fo.
virtual const sc_event& data_read_event() const;
Member functi on data_read_event shall return a reference to an event, the data-r ead event, that i s
noti fied i n the del ta notif icati on phase that occurs at the end of the delta cycl e i n which a val ue i s
read from the f if o.
6.23.10 Member functions for available values and free slots
virtual int num_available() const;
Member function num_available shall return the number of val ues that are available f or readi ng in
the current del ta cycl e. The cal cul ation shal l deduct any val ues read duri ng the current delta cycle
but shall not add any values written during the current delta cycl e.
virtual int num_fr ee() const;
Member function num_fr ee shall return the number of empty sl ots that are f ree for writing in the
current delta cycle. The calculation shal l deduct any slots wri tten during the current del ta cycle but
shal l not add any slots made f ree by reading in the current del ta cycl e.
6.23.11 Diagnostic member functions
virtual void pr int( std::ostream& = std::cout ) const;
Member f uncti on pr int shall print a li st of the val ues stored in the fi fo and that are avail abl e f or
reading. They wil l be printed i n the order they were written to the fi fo and are pri nted to the stream
passed as an argument by call ing oper ator << (std::ostream& , T& ). The f ormatting shal l be
impl ementation-def ined.
virtual void dump( std::ostream& = std::cout ) const;
Member functi on dump shall pri nt at l east the hi erarchical name of the f if o and a l ist of the values
stored i n the fi fo that are avail able f or readi ng. They are pri nted to the stream passed as an argument.
The f ormatting shall be implementation-def ined.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_fifo" .
6.23.12 operator<<
templ ate <class T>
inl ine std::ostream& oper ator << ( std::ostream& , const sc_fi fo<T>& );
oper ator << shal l cal l member f uncti on pr int to pri nt the contents of the f if o passed as the second
argument to the stream passed as the fi rst argument by cal li ng operator oper ator <<
(std::ostream& , T& ).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


178
Copyright 2012 IEEE. All rights reserved.
Exampl e:
SC_MODULE(M)
{
sc_f if o<i nt> f if o;
SC_CTOR(M) : fi fo(4)
{
SC_THREAD(T);
}
void T()
{
int d;
fi fo.write(1);
f if o.pri nt(std::cout); // 1
fi fo.write(2);
f if o.pri nt(std::cout); // 1 2
fi fo.write(3);
f if o.pri nt(std::cout); // 1 2 3
std::cout << f if o.num_avai lable(); // 0 val ues available to read
std::cout << f if o.num_f ree(); // 1 f ree sl ot
f if o.read(d); // read suspends and returns i n the next delta cycl e
f if o.pri nt(std::cout); // 2 3
std::cout << f if o.num_avai lable(); // 2 val ues available to read
std::cout << f if o.num_f ree(); // 1 f ree sl ot
f if o.read(d);
f if o.pri nt(std::cout); // 3
f if o.read(d);
f if o.pri nt(std::cout); // Empty
std::cout << f if o.num_avai lable(); // 0 val ues available to read
std::cout << f if o.num_f ree(); // 1 f ree sl ot
wait(SC_ZERO_TI ME);
std::cout << f if o.num_f ree(); // 4 f ree sl ots
}
} ;
6.24 sc_fifo_in
6.24.1 Description
Cl ass sc_fifo_in i s a speciali zed port cl ass f or use when readi ng from a f if o. I t provi des f unctions to access
conveniently certai n member f unctions of the f if o to which the port is bound.
6.24.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_fifo_in
: publi c sc_port<sc_f if o_i n_i f<T>,0>
{
publ ic:
sc_fifo_in();
expl icit sc_fifo_in( const char* );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


179
Copyright 2012 IEEE. All rights reserved.
virtual ~sc_fifo_in();
void read( T& );
T read();
bool nb_read( T& );
const sc_event& data_wr itten_event() const;
sc_event_f inder& data_wr itten() const;
int num_available() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_fifo_in( const sc_fi fo_in<T>& );
sc_f if o_i n<T>& oper ator = ( const sc_fi fo_in<T>& );
} ;
} // namespace sc_core
6.24.3 Member functions
The constructors shal l pass their arguments to the corresponding constructor for the base class sc_por t.
Member functi ons read, nb_read, data_wr itten_event, and num_available shall each cal l the
corresponding member f unction of the obj ect to which the port is bound using oper ator-> of cl ass sc_por t,
f or example:
T read() { return (* thi s)->read(); }
Member f unction data_wr itten shall return a reference to cl ass sc_event_finder, where the event f inder
object itself shall be constructed using the member function data_wr itten_event (see 5.7).
Member f uncti on kind shall return the string " sc_fifo_in" .
6.25 sc_fifo_out
6.25.1 Description
Cl ass sc_fifo_out i s a speci al ized port cl ass f or use when writing to a f if o. I t provi des f uncti ons to access
conveniently certai n member f unctions of the f if o to which the port is bound.
6.25.2 Class definition
namespace sc_core {
templ ate <class T>
class sc_fifo_out
: publi c sc_port<sc_f if o_out_if <T>,0>
{
publ ic:
sc_fifo_out();
expl icit sc_fifo_out( const char* );
virtual ~sc_fifo_out();
void wr ite( const T& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


180
Copyright 2012 IEEE. All rights reserved.
bool nb_write( const T& );
const sc_event& data_read_event() const;
sc_event_f inder& data_read() const;
int num_fr ee() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_fifo_out( const sc_fi fo_out<T>& );
sc_f if o_out<T>& oper ator = ( const sc_fi fo_out<T>& );
} ;
} // namespace sc_core
6.25.3 Member functions
The constructors shal l pass their arguments to the corresponding constructor for the base class sc_por t.
Member functions wr ite, nb_write, data_read_event, and num_fr ee shal l each call the corresponding
member functi on of the object to whi ch the port i s bound usi ng oper ator-> of class sc_por t, for example:
void wri te( const T& a ) { (* this)->wri te( a ); }
Member f uncti on data_read shall return a reference to class sc_event_finder , where the event f inder obj ect
itsel f shal l be constructed using the member functi on data_read_event (see 5.7).
Member f uncti on kind shall return the string " sc_fifo_out" .
Exampl e:
// Type passed as templ ate argument to sc_fi fo<>
class U
{
publ ic:
U(int val = 0) // If any constructor exi sts, a def aul t constructor is required.
{
ptr = new i nt;
* ptr = val;
}
int get() const { return * ptr; }
void set(i nt i) { * ptr = i; }
// Default assi gnment semanti cs are i nadequate
const U& operator= (const U& arg) { * (thi s->ptr) = * (arg.ptr); return * thi s; }
pri vate:
int * ptr;
} ;
// operator<< required
std::ostream& operator<< (std::ostream& os, const U& arg) { return (os << arg.get()); }
SC_MODULE(M1)
{
sc_f if o_out<U> f if o_out;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


181
Copyright 2012 IEEE. All rights reserved.
SC_CTOR(M1)
{
SC_THREAD(producer);
}
void producer()
{
U u;
f or (i nt i = 0; i < 4; i++)
{
u.set(i);
bool status;
do {
wait(1, SC_NS);
status = f if o_out.nb_wri te(u); // Non-blocki ng write
} whi le (! status);
}
}
} ;
SC_MODULE(M2)
{
sc_f ifo_i n<U> fif o_in;
SC_CTOR(M2)
{
SC_THREAD(consumer);
sensitive << f if o_in.data_written();
}
void consumer()
{
for (;;)
{
wait(f if o_i n.data_written_event());
U u;
bool status = f if o_i n.nb_read(u);
std::cout << u << " "; // 0 1 2 3
}
}
} ;
SC_MODULE(Top)
{
sc_f if o<U> f if o;
M1 m1;
M2 m2;
SC_CTOR(Top)
: m1("m1"), m2("m2")
{
m1.f ifo_out(fi fo);
m2.fi fo_i n (fi fo);
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


182
Copyright 2012 IEEE. All rights reserved.
} ;
6.26 sc_mutex_if
6.26.1 Description
Cl ass sc_mutex_if is an i nterf ace proper and is impl emented by the predef ined channel sc_mutex.
6.26.2 Class definition
namespace sc_core {
class sc_mutex_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual i nt lock() = 0;
virtual i nt trylock() = 0;
virtual i nt unlock() = 0;
protected:
sc_mutex_if();
pri vate:
// Di sabl ed
sc_mutex_if( const sc_mutex_i f& );
sc_mutex_if & oper ator = ( const sc_mutex_if & );
} ;
} // namespace sc_core
6.26.3 Member functions
The behavi or of the member functi ons of cl ass sc_mutex_if is def ined i n cl ass sc_mutex.
6.27 sc_mutex
6.27.1 Description
Cl ass sc_mutex is a predef ined channel intended to model the behavi or of a mutual excl usi on lock used to
control access to a resource shared by concurrent processes. A mutex i s an obj ect of class sc_mutex. A
mutex shal l be i n one of two excl usi ve states: unl ocked or l ocked. Only one process can l ock a given mutex
at one time. A mutex can only be unl ocked by the parti cul ar process instance that locked the mutex but may
be l ocked subsequently by a dif ferent process.
6.27.2 Class definition
namespace sc_core {
class sc_mutex
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


183
Copyright 2012 IEEE. All rights reserved.
: publi c sc_mutex_i f, publ ic sc_object
{
publ ic:
sc_mutex();
expl icit sc_mutex( const char* );
virtual i nt lock();
virtual i nt trylock();
virtual i nt unlock();
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_mutex( const sc_mutex& );
sc_mutex& oper ator = ( const sc_mutex& );
} ;
} // namespace sc_core
6.27.3 Constructors
sc_mutex();
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_object( sc_gen_uni que_name( "mutex" ) )
expl icit sc_mutex( const char* name_ );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_object( name_ )
Both constructors shal l unlock the mutex.
6.27.4 Member functions
virtual int lock();
I f the mutex is unl ocked, member f unction lock shal l lock the mutex and return.
I f the mutex is l ocked, member f uncti on lock shal l suspend until the mutex is unlocked (by another
process). At that poi nt, it shall resume and attempt to lock the mutex by applying these same rul es
agai n.
Member f uncti on lock shall unconditi onal ly return the value 0.
I f mul ti pl e processes attempt to lock the mutex in the same del ta cycl e, the choice of whi ch process
instance is gi ven the l ock in that del ta cycle shall be non-deterministi c; that is, i t wi ll rel y on the
order i n whi ch processes are resumed wi thin the eval uation phase.
virtual int trylock();
I f the mutex i s unlocked, member function trylock shall lock the mutex and shall return the value 0.
I f the mutex i s l ocked, member f uncti on trylock shall immediately return the value 1. The mutex
shal l remain l ocked.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


184
Copyright 2012 IEEE. All rights reserved.
virtual int unlock();
I f the mutex i s unlocked, member function unlock shall return the value 1. The mutex shall remain
unlocked.
I f the mutex was l ocked by a process instance other than the call ing process, member functi on
unlock shall return the value 1. The mutex shall remain locked.
I f the mutex was locked by the call ing process, member f uncti on unlock shall unl ock the mutex and
shal l return the val ue 0. If processes are suspended and are wai ti ng f or the mutex to be unlocked, the
lock shal l be gi ven to exactly one of these processes (the choi ce of process i nstance bei ng non-
determi nisti c) whi le the remaini ng processes shall suspend again. This shall be accompli shed wi thi n
a si ngl e evaluati on phase; that i s, an i mplementati on shall use i mmediate noti ficati on to si gnal the
act of unlocki ng a mutex to other processes.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_mutex" .
6.28 sc_semaphore_if
6.28.1 Description
Cl ass sc_semaphore_if is an i nterf ace proper and is impl emented by the predef ined channel sc_semaphore.
6.28.2 Class definition
namespace sc_core {
class sc_semaphore_if
: vi rtual publi c sc_i nterf ace
{
publ ic:
virtual i nt wait() = 0;
virtual i nt trywait() = 0;
virtual i nt post() = 0;
virtual i nt get_value() const = 0;
protected:
sc_semaphore_if();
pri vate:
// Di sabl ed
sc_semaphore_if( const sc_semaphore_if& );
sc_semaphore_if & oper ator = ( const sc_semaphore_i f& );
} ;
} // namespace sc_core
6.28.3 Member functions
The behavi or of the member functi ons of cl ass sc_semaphore_if is def ined in cl ass sc_semaphor e.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


185
Copyright 2012 IEEE. All rights reserved.
6.29 sc_semaphore
6.29.1 Description
Cl ass sc_semaphore i s a predef ined channel intended to model the behavior of a sof tware semaphore used
to provi de l imi ted concurrent access to a shared resource. A semaphore has an i nteger val ue, the semaphore
val ue, which is set to the permi tted number of concurrent accesses when the semaphore is constructed.
6.29.2 Class definition
namespace sc_core {
class sc_semaphore
: publi c sc_semaphore_if , publ ic sc_obj ect
{
publ ic:
expl icit sc_semaphore( i nt );
sc_semaphore( const char* , i nt );
virtual i nt wait();
virtual i nt trywait();
virtual i nt post();
virtual i nt get_value() const;
virtual const char* kind() const;
pri vate:
// Di sabl ed
sc_semaphore( const sc_semaphore& );
sc_semaphore& oper ator = ( const sc_semaphore& );
} ;
} // namespace sc_core
6.29.3 Constructors
expl icit sc_semaphore( i nt );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_object( sc_gen_uni que_name( "semaphore" ) )
sc_semaphore( const char* name_, i nt );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_object( name_ )
Both constructors shall set the semaphore val ue to the val ue of the int parameter, which shall be non-
negati ve.
6.29.4 Member functions
virtual int wait();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


186
Copyright 2012 IEEE. All rights reserved.
I f the semaphore value is greater than 0, member f unction wait shall decrement the semaphore value
and return.
I f the semaphore value is equal to 0, member f uncti on wait shal l suspend unti l the semaphore value
is incremented (by another process). At that poi nt, i t shall resume and attempt to decrement the
semaphore val ue by applyi ng these same rules agai n.
Member f uncti on wait shall unconditi onal ly return the value 0.
The semaphore value shall not become negati ve. I f multiple processes attempt to decrement the
semaphore value in the same del ta cycle, the choi ce of whi ch process instance decrements the
semaphore value and which processes suspend shall be non-determi ni stic; that is, i t wi ll rel y on the
order i n whi ch processes are resumed wi thin the eval uation phase.
virtual int trywait();
I f the semaphore value is greater than 0, member f unction trywait shal l decrement the semaphore
val ue and shall return the val ue 0.
I f the semaphore value i s equal to 0, member function tr ywait shall immediately return the value 1
wi thout modif yi ng the semaphore val ue.
virtual int post();
Member functi on post shall i ncrement the semaphore value. I f processes exist that are suspended
and are wai ti ng f or the semaphore val ue to be i ncremented, exactl y one of these processes shal l be
permi tted to decrement the semaphore val ue (the choice of process instance being non-
determi nisti c) whi le the remaini ng processes shall suspend again. This shall be accompli shed wi thi n
a si ngl e evaluati on phase; that i s, an i mplementati on shall use i mmediate noti ficati on to si gnal the
act of incrementi ng the semaphore val ue to any wai ti ng processes.
Member f uncti on post shall unconditi onal ly return the value 0.
virtual int get_value() const;
Member f uncti on get_value shall return the semaphore value.
virtual const char* kind() const;
Member f uncti on kind shal l return the string " sc_semaphore" .
NOTE 1The semaphore value may be decremented and i ncremented by di f f erent processes.
NOTE 2The semaphore value may exceed the value set by the constructor.
6.30 sc_event_queue
6.30.1 Description
Cl ass sc_event_queue represents an event queue. Like cl ass sc_event, an event queue has a member
functi on notify. Unl ike an sc_event, an event queue is a hierarchical channel and can have multiple
notif icati ons pending.
6.30.2 Class definition
namespace sc_core {
class sc_event_queue_if
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


187
Copyright 2012 IEEE. All rights reserved.
: publi c vi rtual sc_i nterf ace
{
publ ic:
virtual void notify( double , sc_time_unit ) = 0;
virtual void notify( const sc_ti me& ) = 0;
virtual void cancel_all() = 0;
} ;
class sc_event_queue
: publi c sc_event_queue_if , publ ic sc_modul e
{
publ ic:
sc_event_queue( sc_modul e_name name_=
sc_module_name(sc_gen_unique_name(event_queue)));
~sc_event_queue();
virtual const char* kind() const;
virtual void notify( double , sc_time_unit );
virtual void notify( const sc_ti me& );
virtual void cancel_all();
virtual const sc_event& default_event() const;
} ;
} // namespace sc_core
6.30.3 Constraints on usage
Cl ass sc_event_queue i s a hierarchi cal channel , and thus, sc_event_queue objects can only be constructed
duri ng elaborati on.
NOTEAn object of class sc_event_queue cannot be used i n most contexts requi ri ng an sc_event but can be used to
create stati c sensi ti vi ty because i t i mpl ements member f unction sc_inter face::default_event.
6.30.4 Constructors
sc_event_queue( sc_module_name name_= sc_module_name(sc_gen_unique_name(event_queue)));
This constructor shal l pass the module name argument through to the constructor for the base class
sc_module.
6.30.5 kind
Member f uncti on kind shall return the string " sc_event_queue" .
6.30.6 Member functions
virtual void notify( double , sc_time_unit );
virtual void notify( const sc_ti me& );
A call to member f uncti on notify wi th an argument that represents a zero time shall cause a del ta
noti ficati on on the def aul t event.
A call to functi on notify wi th an argument that represents a non-zero time shall cause a timed
noti ficati on on the default event at the given ti me, expressed rel ative to the simul ation time when
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


188
Copyright 2012 IEEE. All rights reserved.
f uncti on notify i s cal led. In other words, the value of the time argument i s added to the current
simul ation ti me to determine the time at whi ch the event wi ll be noti fied.
I f f uncti on notify i s call ed when there is a al ready one or more notif ications pending, the new
noti ficati on shal l be queued i n addi ti on to the pending noti fi cations. Each queued notif icati on shal l
occur at the ti me determined by the semantics of function notify, i rrespective of the order i n which
the cal ls to notify are made.
The defaul t event shal l not be notif ied more than once in any one del ta cycl e. I f multiple
noti ficati ons are pendi ng f or the same del ta cycl e, those noti fi cati ons shal l occur in successive del ta
cycl es. I f mul ti ple ti med notif icati on are pending f or the same si mulati on ti me, those noti fi cati ons
shal l occur in successive del ta cycl es starting wi th the f irst del ta cycl e at that si mulati on time step
and wi th no gaps i n the del ta cycl e sequence.
virtual void cancel_all();
Member f uncti on cancel_all shall immedi atel y del ete every pendi ng noti ficati on f or thi s event
queue object including both delta and ti med noti fi cati ons, but i t shall have no ef fect on other event
queue obj ects.
virtual const sc_event& default_event() const;
Member f uncti on default_event shal l return a ref erence to the default event.
The mechanism used to queue noti ficati ons shal l be impl ementation-defi ned, with the proviso that
an event queue object must provi de a single default event that is notif ied once for every cal l to
member f uncti on notify.
NOTEEvent queue notifications are anonymous i n the sense that the onl y inf ormati on carri ed by the defaul t
event i s the ti me of noti f i cati on. A process i nstance sensi ti ve to the def aul t event cannot tel l whi ch cal l to
f uncti on notify caused the noti f i cation.
Exampl e:
sc_event_queue EQ;
SC_CTOR(Mod)
{
SC_THREAD(T);
SC_METHOD(M);
sensitive << EQ;
dont_initiali ze();
}
void T()
{
EQ.notif y(2, SC_NS); // M runs at time 2ns
EQ.notif y(1, SC_NS); // M runs at time 1ns, 1
st
or 2
nd
del ta cycle
EQ.notif y(SC_ZERO_TIME); // M runs at time 0ns
EQ.notif y(1, SC_NS); // M runs at time 1ns, 2
nd
or 1
st
del ta cycle
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


189
Copyright 2012 IEEE. All rights reserved.
7. SystemC data types
7.1 Introduction
Al l native C++ types are supported within a SystemC appl ication. SystemC provides addi tional data type
classes within thesc_dt namespaceto represent valueswith appl icati on-speci fi c word lengthsappl icabl eto
digi tal hardware. Thesedatatypesarereferred to asSystemC data types.
TheSystemCdatatypeclassesconsi st of thefol lowing:
Li mi ted-pr eci si on i nteger s, which areclassesderi ved fromclasssc_i nt_base, cl ass sc_uint_base, or
instances of such cl asses. A li mi ted-precision integer shall represent a signed or unsi gned integer
val ueat apreci si onli mi tedby itsunderlying nati veC++ representation and i tsspecified wordlength.
Fi ni te-pr eci si on i nteger s, which are cl asses deri ved from class sc_signed, class sc_unsi gned, or
instancesof such cl asses. A fini te-preci si oninteger shall represent asigned or unsigned integer val ue
at apreci si onl imited onl y by i tsspecified word length.
Fi ni te-pr eci si on fi xed-poi nt types, which are classes derived from cl ass sc_fxnum or instances of
such cl asses. A fi nite-preci sion fi xed-point type shal l represent a signed or unsigned fixed-point
val ue at a precision l imi ted onl y by i ts speci fi ed word length, integer word l ength, quantization
mode, and overflow mode.
Li mi ted-pr eci si on fi xed-poi nt types, whi ch areclassesderivedfromclasssc_fxnum_fast or instances
of such classes. A l imited-preci si onfixed-point typeshal l represent asi gned or unsi gned fi xed-poi nt
val ueat a preci si on li mited by itsunderlying nati veC++ floati ng-point representation and i tsspeci-
fiedword l ength, i nteger word l ength, quantizati on mode, and overflow mode.
Vari abl e-preci si on fi xed-poi nt type, which is the cl ass sc_fxval. A variable-preci si on fixed-point
typeshall represent afi xed-point valuewithapreci sion that may vary over timeandi snot subj ect to
quantization or overfl ow.
Li mi ted var i abl e-pr eci si on fi xed-poi nt type, which i s the class sc_fxval _fast. A li mited vari abl e-
precision fixed-point type shal l represent a fi xed-poi nt value wi th a preci si on that is l imi ted by i ts
underlying C++ fl oati ng-point representati on and that may vary over ti me and i s not subj ect to
quantization or overfl ow.
Si ngl e-bi t l ogi c types impl ement a four-val ued logic data type with states l ogi c 0, l ogi c 1, hi gh-
i mpedance, and unknown and shall berepresented by thesymbol s ' 0' , ' 1' , ' X' , and 'Z' , respectively.
The lowercase symbols ' x' and 'z' are acceptabl e alternatives for ' X' and ' Z' , respectively, as
character literals assigned tosi ngl e-bit l ogi c types.
Bi t vector s, whi ch are cl asses deri ved from cl ass sc_bv_base, or instances of such cl asses. A bit
vector shal l i mplement amul ti plebit datatype, whereeach bi t hasastateof l ogi c 0 or l ogi c 1 and i s
representedby thesymbols ' 0' or ' 1', respecti vel y.
Logi c vector s, which arecl assesderived fromclasssc_l v_base, or i nstancesof such classes. A logic
vector shall impl ement a multipl e-bit data type, whereeach bit hasa state of l ogi c 0, l ogi c 1, hi gh-
i mpedance, or unknown and isrepresented by thesymbol s' 0' , ' 1', ' X' , or 'Z' . Thelowercasesymbols
' x' and 'z' are acceptable alternativesfor ' X' and ' Z' , respectivel y, within string li terals assi gned to
logic vectors.
Apart from the si ngle-bit logi c types, the vari abl e-precision fi xed-poi nt types, and the limited vari abl e-
precision fixed-poi nt types, the classes within each category are organized as an object-ori ented hi erarchy
wi th common behavi or definedin baseclasses. A cl asstemplateshal l bederivedfromeach basecl assby the
impl ementation such that appl icationscan speci fy wordl engthsastempl atearguments.
Theterm fi xed-poi nt type i s used in thi sstandard to refer to any finite-precision fixed-poi nt typeor li mi ted-
precision fi xed-point type. Thevariabl e-precision and l imi ted vari abl e-precision fi xed-poi nt typesarefixed-
point types onl y in the restricted sense that they store a representation of a fi xed-poi nt val ue and can be
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


190
Copyright 2012 IEEE. All rights reserved.
mi xed with other fi xed-poi nt types i n expressions, but they are not f ixed-poi nt types in the sense that they do
not model quanti zation or overfl ow ef fects and are not intended to be used directl y by an appli cation.
The term numer i c type is used i n this standard to refer to any l imi ted-preci si on integer, fi nite-precision
integer, fi nite-preci sion f ixed-point type, or l imi ted-precisi on fi xed-poi nt type. The term vector is used to
ref er to any bi t vector or l ogi c vector. The word l ength of a numeric type or vector object shall be set when
the object is i ni ti al ized and shall not subsequentl y be altered. Each bi t withi n a word shall have an index. The
right-hand bi t shal l have index 0 and is the least-signif icant bit f or numeri c types. The i ndex of the lef t-hand
bit shall be the word length mi nus 1.
The li mi ted-precision signed i nteger base class is sc_int_base. The l imited-preci si on unsigned integer base
class i s sc_uint_base. The correspondi ng class templ ates are sc_int and sc_uint, respecti vel y.
The fi nite-precision si gned i nteger base cl ass i s sc_signed. The f ini te-precisi on unsigned i nteger base cl ass
is sc_unsigned. The correspondi ng class templ ates are sc_bigint and sc_biguint, respecti vel y.
The si gned f ini te-precisi on fixed-point base class is sc_fix. The unsi gned f ini te-precision f ixed-point base
class i s sc_ufix. Both base classes are deri ved f rom cl ass sc_fxnum. The correspondi ng cl ass templ ates are
sc_fixed and sc_ufixed, respecti vel y.
The signed li mited-precision f ixed-poi nt base class is sc_fix_fast. The unsigned li mited-precision f ixed-
point base class is sc_ufix_fast. Both base classes are deri ved from classsc_fxnum_fast. The correspondi ng
class templ ates are sc_fixed_fast and sc_ufixed_fast, respecti vel y.
The vari abl e-precision fi xed-point cl ass is sc_fxval. The l imited variable-preci si on f ixed-point class i s
sc_fxval_fast. These two classes are used as the operand types and return types of many fi xed-poi nt
operations.
The bi t vector base cl ass i s sc_bv_base. The correspondi ng class templ ate i s sc_bv.
The l ogi c vector base class is sc_lv_base. The correspondi ng class templ ate i s sc_lv.
The single-bi t l ogi c type is sc_logic.
I t is recommended that appli cati ons create SystemC data type objects using the class templ ates gi ven in thi s
clause (f or exampl e, sc_int) rather than the untempl ated base cl asses (for example, sc_int_base).
The rel ati onships between the SystemC data type cl asses are shown in Tabl e 4.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


191
Copyright 2012 IEEE. All rights reserved.
7.2 Common characteristics
This subcl ause speci fi es some common characteri stics of the SystemC data types such as common operators
and functions. This subclause should be taken as speci f yi ng a set of obl igati ons on the impl ementation to
provide operators and f uncti ons wi th the gi ven behavi or. In some cases the i mplementati on has some
f lexi bil ity wi th regard to how the given behavior is impl emented. The remainder of Cl ause 7 gi ves a detai led
def ini ti on of the SystemC data type classes.
An underlyi ng principl e is that native C++ integer and f loati ng-poi nt types, C++ stri ng types, and SystemC
data types may be mi xed in expressions.
Equal ity and bi twise operators can be used f or all SystemC data types. Ari thmeti c and relational operators
can be used wi th the numeri c types only. The semanti cs of the equali ty operators, bitwise operators,
ari thmeti c operators, and relational operators are the same i n SystemC as i n C++.
User-defi ned conversi ons suppl ied by the i mplementation support translati on from SystemC types to C++
native types and other SystemC types.
Bit-select, part-sel ect, and concatenation operators return an instance of a proxy class. The term proxy cl ass
is used i n this standard to refer to a cl ass whose purpose is to represent a SystemC data type obj ect withi n an
expression and which provi des addi tional operators or f eatures not otherwi se present i n the represented
object. An example is a proxy cl ass that all ows an sc_int variable to be used as i f it were a C++ array of bool
and to disti ngui sh between its use as an rvalue or an l val ue withi n an expression. Instances of proxy cl asses
are only i ntended to be used wi thi n the expressions that create them. An appl i cation shoul d not cal l a proxy
Table 4SystemC data types
Class template Base class Gener ic base class Repr esentation Precision
sc_i nt sc_i nt_base sc_val ue_base si gned i nteger l i mi ted
sc_ui nt sc_ui nt_base sc_val ue_base unsi gned integer l i mi ted
sc_bi gi nt sc_si gned sc_val ue_base si gned i nteger f i ni te
sc_bi gui nt sc_unsi gned sc_val ue_base unsi gned i nteger f i ni te
sc_fi xed sc_f i x sc_f xnum si gned f i xed-poi nt f i ni te
sc_uf i xed sc_ufi x sc_f xnum unsi gned f i xed-poi nt f i ni te
sc_fi xed_fast sc_f ix_f ast sc_f xnum_fast si gned f i xed-poi nt l imi ted
sc_uf i xed_f ast sc_uf i x_f ast sc_f xnum_fast unsi gned f i xed-poi nt l i mi ted
sc_fxval f i xed-poi nt vari able
sc_fxval _f ast f i xed-poi nt l i mi ted-vari abl e
sc_l ogi c si ngl e bi t
sc_bv sc_bv_base bi t vector
sc_l v sc_l v_base l ogi c vector
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


192
Copyright 2012 IEEE. All rights reserved.
class constructor to createanamed obj ect and should not decl areapointer or referencetoaproxy class. It is
strongly recommended that an appli cation avoid the use of a proxy class as the return type of a functi on
becausetheli fetimeof theobj ect to which theproxy class refers may not extend beyond thefuncti onreturn
statement.
NOTE 1The bitwise shift left or shift right operation hasnomeaning for asingle-bit logic typeand isundefined.
NOTE 2The termuser -defi ned conver sions inthiscontext has thesamemeaningasin theC++ standard. It appliesto
type conversions of class objects by calling constructors and conversion functions that are used for implicit type
conversions and explicit typeconversions.
NOTE 3Care should be taken when mixing signed and unsigned numeric types in expressions that useimplicit type
conversions sincean implementationisnot requiredto issueawarning if thepolarity of aconvertedvalueischanged.
7.2.1 Initialization and assignment operators
Overl oaded constructors shall be provided by the i mplementation for al l i nteger (li mited-preci si on integer
and fi ni te-preci si on integer) class templates that all ow i ni ti ali zati on with an object of any SystemC data
type.
Overl oaded constructors shall be provided for al l vector (bit vector and l ogic vector) class templates that
all ow i nitiali zation withan obj ect of any SystemCi nteger or vector datatype.
Overloaded constructors shall be provided for all fini te-preci si on fixed-poi nt and l imi ted preci si on fixed-
point classtempl atesthat al low ini ti al ization wi th an object of any SystemCinteger datatype.
Al l SystemCdatatypeclassesshal l defineacopy constructor that createsacopy of thespeci fi edobject with
thesameval ueand thesameword length.
Overl oaded assi gnment operators and constructors shall perform di rect or indi rect conversion between
types. The data type basecl asses may define arestricted set of constructors and assi gnment operators that
only permi t direct initial ization froma subset of the SystemC datatypes. As a general principl e, data type
class templ ate constructors may be cal led impli ci tl y by an appli cation to perform conversion from other
typessincetheir word l ength isspeci fi ed by atempl ateargument. Ontheother hand, thedatatypebasecl ass
constructors wi th a single parameter of a di fferent type should only be cal led expl icitly si nce the required
word l ength is not specified.
If thetarget of an assi gnment operation has awordl engththat isi nsuffici ent to hol d thevalueassi gned to i t,
thel eft-hand bi tsof thevaluestored shal l betruncated to fit thetarget word length. If truncation occurs, an
implementation may generate a warni ng but i s not obl iged to do so, and an appli cation can in any case
disabl esuch awarning (see3.3.5).
If adata typeobject or string li teral i sassi gned to atarget havi ng a greater word l ength, the val ue shall be
extended with additional bits at i ts left-hand si de to match the target word l ength. Extension of a si gned
numeri c typeshall preservebothi ts si gn and magni tudeand isreferredtoassi gn extensi on. Extension of all
other types shall i nsert bitswi th avalueof logic 0 and is referred to as zer o extensi on.
Assi gnment of a fi xed-poi nt type to an integer type shal l use the i nteger component only; any fractional
component is discarded.
Assi gnment of avaluewithaword length greater than 1to asingle-bit logic typeshall bean error.
NOTEAn integer literal is always treated as unsigned unless prefixedby aminus symbol. An unsigned integer literal
will always beextended with leading zeroswhen assigned to adatatypeobject having alarger word length, regardless
of whether theobject itself issigned or unsigned.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


193
Copyright 2012 IEEE. All rights reserved.
7.2.2 Precision of arithmetic expressions
The type of the value returned by any arithmetic expression containing onl y l imi ted-precisi on integers or
li mi ted-precision i ntegers and native C++ i nteger types shal l be an impl ementation-defi ned C++ integer type
wi th a maxi mum word l ength of 64 bi ts. The acti on taken by an impl ementation i f the precision required by
the return value exceeds 64 bi ts i s undef ined and the val ue is impl ementation-dependent.
The val ue returned by any ari thmeti c expressi on containi ng onl y f ini te-precisi on i ntegers or f inite-precision
integers and any combinati on of li mi ted-precision or nati ve C++ integer types shall be a fi ni te-preci si on
integer wi th a word-l ength suff icient to contain the val ue wi th no l oss of accuracy.
The val ue returned by any ari thmeti c expression contai ning any fi xed-poi nt type shall be a vari abl e-
precision or li mi ted vari abl e-precisi on fi xed-point type (see 7.10.4).
Appli cati ons should use expl ici t type casts withi n expressions combining multiple types where an
impl ementation does not provi de overl oaded operators wi th si gnatures exactl y matchi ng the operand types.
Exampl e:
int i = 10;
sc_dt::i nt64 i 64 = 100; // long long i nt
sc_i nt<16> sci = 2;
sc_bigi nt<16> bi = 20;
fl oat f = 2.5;
sc_f ixed<16,8> scf = 2.5;
( i * sci ); // Ambiguous
( i * static_cast<sc_dt::i nt_type>(sci) ); // Impl ementation-defi ned C++ integer
( i * bi ); // 48-bit fi ni te-preci si on i nteger (assumes int = 32 bits)
( i 64 * bi ); // 80-bit fi ni te-precision integer
( f * bi ); // Ambiguous
( static_cast<int>(f ) * bi ); // 48-bit fi nite-precision integer (assumes int = 32 bits)
( scf * sci ); // Vari able-preci si on f ixed-point type
7.2.3 Base class default word length
The def ault word length of a data type base class shal l be used where i ts def aul t constructor is call ed
(impli citly or expli ci tl y). The def aul t word length shall be set by the l ength par ameter in context at the poi nt
of construction. A l ength parameter may be brought into context by creati ng a l ength context obj ect. Length
contexts shall have local scope and by def aul t be activated i mmediately. Once activated, they shal l remain in
eff ect f or as long as they are i n scope, or unti l another l ength context i s activated. Acti vation of a length
context shall be def erred i f its second constructor argument i s SC_LATER (the default value is SC_NOW).
A deferred l ength context can be activated by cal li ng i ts member function begin.
Length contexts shall be managed by a global l ength context stack. When a length context i s activated, it
shal l be pl aced at the top of the stack. A l ength context may be deactivated and removed f rom the top of the
stack by call ing its member f uncti on end. The end method shal l onl y be call ed f or the l ength context
currentl y at the top of the context stack. A length context i s i mpli citl y deacti vated and removed f rom the
stack when i t goes out of scope. A deferred l ength context that has been activated by cal li ng i ts member
functi on begin should be expl icitly deactivated and removed from the stack by call ing i ts member functi on
end. The current context shal l always be the length context at the top of the stack.
A length context shall onl y be acti vated once. An active length context shall onl y be deacti vated once.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


194
Copyright 2012 IEEE. All rights reserved.
The classes sc_length_param and sc_length_context shall be used to create l ength parameters and length
contexts, respectively, for SystemC integers and vectors.
I n addi ti on to the word length, the fi xed-point types shal l have default i nteger word length and mode
attri butes. These shall be set by the fi xed-poi nt type par ameter in context at the point of constructi on. A
f ixed-poi nt type parameter shall be brought i nto context by creating a fi xed-poi nt type context obj ect. The
use of a f ixed-point type context shall f oll ow the same rul es as a l ength context. A stack for f ixed-point type
contexts wi th the same characteristi cs as the length context stack shall exist.
The cl asses sc_fxtype_params and sc_fxtype_context shal l be used to create f ixed-poi nt type parameters
and f ixed-poi nt type contexts, respecti vel y.
Exampl e:
sc_length_param length10(10);
sc_length_context cntxt10(length10); // l ength10 now i n context
sc_i nt_base i nt_array[ 2] ; // Array of 10-bit integers
sc_core::sc_si gnal <sc_int_base> S1; // Signal of 10-bi t i nteger
{
sc_l ength_param length12(12);
sc_l ength_context cntxt12(length12,SC_LATER); // cntxt12 def erred
sc_l ength_param length14(14);
sc_l ength_context cntxt14(length14,SC_LATER); // cntxt14 def erred
sc_ui nt_base var1; // l ength 10
cntxt12.begi n(); // Bring length12 i nto context
sc_ui nt_base var2; // l ength 12
cntxt14.begi n(); // Bring length14 i nto context
sc_ui nt_base var3; // l ength 14
cntxt14.end(); // end cntx14, cntx12 restored
sc_bv_base var4; // l ength 12
} // cntxt12 out of scope, cntx10 restored
sc_bv_base var5; // l ength 10
NOTE 1The context stacks allow a def aul t context to be local l y repl aced by an alternative context and subsequentl y
restored.
NOTE 2An activated context remains acti ve f or thel i f eti me of the context obj ect or unti l i t i sexpli ci tl y deactivated. A
context can theref ore af fect the def aul t parameters of data type obj ects created outsi de of the functi on i n whi ch i t i s
activated. An appl i cation should ensure that any contexts created or activated wi thin f uncti ons whose executi on order i s
non-determi ni stic do not resul t i n temporal orderi ng dependenci es i n other parts of the appl i cati on. Fai l ure to meet thi s
condi ti on coul d resul t i n behavi or that i s i mplementati on-dependent.
7.2.4 Word length
The word l ength (a positive integer indicati ng the number of bits) of a SystemC i nteger, vector, part-sel ect,
or concatenation shall be returned by the member f uncti on length.
7.2.5 Bit-select
Bi t-sel ects are instances of a proxy class that reference the bi t at the speci fi ed posi tion withi n an associ ated
object that i s a SystemC numeri c type or vector.
The C++ subscri pt operator (oper ator [] ) shal l be overloaded by the implementati on to create a bit-select
when cal led wi th a single non-negative i nteger argument speci f yi ng the bi t position. I t shal l be an error i f the
specif ied bi t posi ti on i s outside the bounds of i ts numeric type or vector obj ect.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


195
Copyright 2012 IEEE. All rights reserved.
User-def ined conversions shall all ow bit-selects to be used i n expressions where a bool obj ect operand is
expected. A bi t-select of an lvalue may be used as an rval ue or an lvalue. A bi t-select of an rvalue shall only
be used as an rvalue.
A bit-sel ect or a bool val ue may be assigned to an l val ue bit-sel ect. The assignment shall modi fy the state of
the selected bi t wi thin the associated numeric type or vector object represented by the lvalue. An appl ication
shall not assign a value to an rval ue bi t-select.
Bit-selects f or integer, bit vector, and logic vector types shal l have an expli cit to_bool conversi on f uncti on
that returns the state of the selected bi t.
Exampl e:
sc_int<4> I 1; // 4 bi t signed i nteger
I 1[ 1] = true; // Selected bit used as l val ue
bool b0 = I 1[ 0].to_bool(); // Selected bit used as rvalue
NOTE 1Bit-selects corresponding to lvalues and rvalues of a particular type are themsel ves objects of two disti nct
cl asses.
NOTE 2A bit-select class can contain user-defined conversions for both impl i ci t and expl ici t conversion of the
sel ected bi t val ue to bool .
7.2.6 Part-select
Part-sel ects are instances of a proxy class that provi de access to a conti guous subset of bi ts wi thin an
associ ated object that i s a numeric type or vector.
The member f unction r ange( int , int ) of a numeri c type, bit vector, or l ogic vector shall create a part-select.
The two non-negati ve integer arguments speci fy the l eft- and ri ght-hand index positions. A part-sel ect shall
provide a reference to a word within its associated obj ect, starting at the l ef t-hand index position and
extendi ng to, and i ncl udi ng, the right-hand i ndex posi ti on. I t shal l be an error if the l ef t-hand index position
or right-hand index posi ti on l ies outside the bounds of the object.
The C++ functi on call operator (oper ator ()) shall be overl oaded by the i mplementati on to create a part-
sel ect and may be used as a direct replacement f or the r ange functi on.
User-def ined conversions shall all ow a part-sel ect to be used i n expressions where the expected operand is
an object of the numeric type or vector type associated wi th the part-sel ect, subj ect to certai n constraints (see
7.5.7.3, 7.6.8.3, and 7.9.8.3). A part-sel ect of an lvalue may be used as an rvalue or as an l value. A part-
sel ect of an rval ue shal l only be used as an rvalue.
I nteger part-sel ects may be di rectl y assigned to an object of any other SystemC data type, wi th the
excepti on of bi t-sel ects. Fixed-point part-sel ects may be directl y assigned to any SystemC i nteger or vector,
any part-select or any concatenation. Vector part-sel ects may onl y be di rectly assi gned to a vector, vector
part-sel ect, or vector concatenation (assi gnments to other types are ambiguous or require an expli cit
conversion).
The bits wi thin a part-sel ect do not ref lect the si gn of thei r associ ated object and shal l be taken as
representing an unsi gned binary number when converted to a numeric val ue. Assignments of part-selects to
a target having a greater word length shall be zero extended, regardl ess of the type of their associated obj ect.
Exampl e:
sc_int<8> I2 = 2; // "0b00000010"
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


196
Copyright 2012 IEEE. All rights reserved.
I 2.range(3,2) = I2.range(1,0); // "0b00001010"
sc_int<8> I 3 = I2.range(3,0); // "0b00001010"
// Zero-extended to 8 bi ts
sc_bv<8> b1 = "0b11110000";
b1.range(5,2) = b1.range(2,5); // "0b11001100"
// Reversed bi t-order between posi ti on 5 and 2
NOTE 1A part-select cannot be used to reverse the bi t-order of a l i mi ted-preci si on i nteger type.
NOTE 2Part-selects corresponding to lvalues and rval ues of a particul ar type are themsel ves obj ects of two di sti nct
cl asses.
NOTE 3A part-select is not required to be an acceptabl e repl acement where an obj ect ref erence operand i s expected. I f
an impl ementation provi des a mechani sm to al l ow such repl acements (for exampl e, by def i ni ng the appropri ate
overl oaded member f uncti ons), i t i s not requi red to do so f or al l data types.
7.2.7 Concatenation
Concatenati ons are instances of a proxy cl ass that ref erence the bits wi thin multiple obj ects as i f they were
part of a single aggregate obj ect.
The concat( arg0 , arg1 ) function shal l create a concatenati on. The concatenati on ar guments (arg0 and
arg1) may be two SystemC integer, vector, bit-sel ect, part-sel ect, or concatenati on objects. The C++ comma
operator (oper ator,) shal l al so be overl oaded to create a concatenati on and may be used as a di rect
replacement for the concat functi on.
The type of a concatenation argument shal l be a concatenati on base type, or it shal l be derived f rom a
concatenation base type. An i mplementati on shall provi de a common concatenation base type for all
SystemC i ntegers and a common concatenation base type f or all vectors. The concatenati on base type of bit-
sel ect and part-sel ect concatenation arguments is the same as thei r associated integer or vector obj ects. The
concatenation arguments may be any combinati on of two obj ects having the same concatenati on base type.
A concatenati on object shal l have the same concatenation base type as the concatenation arguments passed
to the functi on that created the object. The set of permi ssi bl e concatenation arguments f or a given
concatenation base type consists of the fol lowi ng:
a) Objects whose base class or concatenati on base type matches the gi ven concatenation base type
b) Bi t-selects of item a)
c) Part-selects of i tem a)
d) Concatenati ons of item a) and/or item b) and/or item c) in any combination
When both concatenation arguments are lvalues, the concatenati on shal l be an l val ue. I f any concatenation
argument is an rval ue, the concatenation shall be an rval ue.
A si ngl e concatenation argument may be a bool val ue when the other argument is a SystemC i nteger, vector,
bit-sel ect, part-select, or concatenation obj ect. The resulting concatenation shall be an rval ue.
An expressi on may be assigned to an l val ue concatenati on if the base type of the expression return val ue is
the same as the base type of the lvalue concatenati on. If the word length of a val ue assigned to a
concatenation wi th a si gned base type i s small er than the word length of the concatenati on, the value shal l be
sign-extended to match the word l ength of the concatenation. Assignments to concatenations of al l other
numeri c types and vectors shal l be zero-extended (if requi red). Assi gnment to a concatenati on shall update
the val ues of the objects speci fi ed by i ts concatenati on arguments.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


197
Copyright 2012 IEEE. All rights reserved.
A concatenati on may be assi gned to an object whose base cl ass i s the same as the concatenati on base type.
Where a concatenati on i s assigned to a target having a greater word l ength than the concatenation, i t i s zero-
extended to the target length. When a concatenati on i s assigned to a target havi ng a shorter word length than
the concatenation, the l ef t-hand bits of the val ue shall be truncated to fi t the target word l ength. If truncati on
occurs, an i mplementati on may generate a warni ng but i s not obliged to do so, and an applicati on can i n any
case di sable such a warning (see 3.3.5).
Exampl e:
The f oll owi ng concatenations are wel l-formed:
sc_uint<8> U1 = 2; // "0b00000010"
sc_uint<2> U2 = 1; // "0b01"
sc_uint<8> U3 = (true,U1.range(3,0),U2,U2[ 0]); // U3 = "0b10010011"
// Base cl ass same as concatenation base type
(U2[0],U1[ 0],U1.range(7,1)) = (U1[7],U1); // Copies U1[ 7] to U2[ 0] , U1 rotated lef t
concat(U2[0],concat(U1[ 0] ,U1.range(7,1))) = concat(U1[ 7] ,U1);
// Same as previ ous example but usi ng concat
The f oll owi ng concatenati ons are il l-formed:
sc_bv<8> Bv1;
(Bv1,U1) = "0xff ff "; // Bv1 and U1 do not share common base type
bool C1=true; bool C2 = fal se;
U2 = (C1,C1); // Cannot concatenate 2 bool obj ects
(C1,I 1) = "0x1f f"; // Bool concatenation argument creates rvalue
NOTE 1Parentheses are required around the concatenation arguments when usi ng the C++ comma operator because
of i ts l ow operator precedence.
NOTE 2An implementation is not requi red to support bi t-sel ects and part-sel ects of concatenati ons.
NOTE 3Concatenations corresponding to lvalues and rval ues of a parti cul ar type are themsel ves objects of two
di sti nct cl asses.
7.2.8 Reduction operators
The reduction operators shal l perf orm a sequence of bi twise operations on a SystemC i nteger or vector to
produce a bool result. The fi rst step shall be a boolean operation appl ied to the f irst and second bits of the
object. The boolean operation shal l then be re-appl ied usi ng the previ ous resul t and the next bi t of the object.
This process shal l be repeated unti l every bi t of the object has been processed. The value returned shall be
the resul t of the f inal bool ean operation. The f ol lowi ng reducti on operators shall be provi ded:
a) and_r educe performs a bitwise AND between all bi ts.
b) nand_r educe performs a bitwise NAND between all bits.
c) or_r educe performs a bitwise OR between all bi ts.
d) nor_reduce perf orms a bitwi se NOR between all bi ts.
e) xor_reduce performs a bitwise XOR between all bi ts.
f) xnor _reduce performs a bitwise XNOR between all bits.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


198
Copyright 2012 IEEE. All rights reserved.
7.2.9 Integer conversion
Al l SystemC data types shal l provi de an assignment operator that can accept a C++ i nteger value. A signed
val ue shal l be si gn-extended to match the l ength of the SystemC data type target.
SystemC data types shall provi de member f unctions f or expl ici t type conversi on to C++ integer types as
fol lows:
a) to_int converts to native C++ int type.
b) to_uint converts to nati ve C++ unsigned type.
c) to_long converts to native C++ long type.
d) to_ulong converts to nati ve C++ unsigned long type.
e) to_uint64() converts to a native C++ unsigned i nteger type havi ng a word l ength of 64 bits.
f) to_int64() converts to nati ve C++ integer type havi ng a word length of 64 bi ts.
These member f uncti ons shal l i nterpret the bits within a SystemC integer, f ixed-point type or vector, or any
part-sel ect or concatenation thereof , as representi ng an unsigned binary val ue, wi th the excepti on of si gned
integers and signed f ixed-point types.
Truncation shall be perf ormed where necessary for the value to be represented as a C++ i nteger.
Attempti ng to convert a logic vector containi ng 'X ' or 'Z ' val ues to an i nteger shall be an error.
7.2.10 String input and output
void scan( std::i stream& i s = std::ci n );
void pr int( std::ostream& os = std::cout ) const;
Al l SystemC data types shall provi de a member f unction scan that allows an obj ect value to be set
by reading a string f rom the speci fi ed C++ i nput stream. The stri ng content may use any of the
representations permitted by 7.3.
Al l SystemC data types shal l provi de a member f unction pr int that al lows an object value to be
written to a C++ output stream.
SystemC numeri c types shal l be pri nted as si gned or unsigned decimal values. SystemC vector types
shal l be printed as a string of bit val ues.
Al l SystemC data types shall support the output stream i nserter (oper ator <<) for f ormatted printi ng
to a C++ stream. The f ormat shal l be the same as f or the member functi on pr int.
The C++ ostream mani pul ators dec, oct, and hex shall have the same ef f ect f or li mited-preci si on
and f inite-precision integers and vector types as they do for standard C++ integers: that i s, they shall
cause the val ues of such obj ects to be pri nted in decimal , octal, or hexadeci mal formats,
respecti vel y. The formats used shall be those descri bed i n 7.3 with the exception that vectors shal l
be printed as a bi t-pattern string when the dec manipulator is acti ve.
Al l SystemC data types shal l support the i nput stream i nserter (oper ator >>) for f ormatted input
f rom a C++ i nput stream. The permi tted f ormats shall be the same as those permi tted f or the member
f uncti on scan.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


199
Copyright 2012 IEEE. All rights reserved.
void dump ( std::ostream& os = std::cout ) const;
Al l f ixed-poi nt types shall additional ly provide a member functi on dump that shal l print at least the
type name and value to the stream passed as an argument. The purpose of dump i s to all ow an
impl ementation to dump out diagnosti c i nf ormation to hel p the user debug an appl ication.
7.2.11 Conversion of application-defined types in integer expressions
The generi c base proxy cl ass templ atesc_gener ic_base shall be provided by the i mplementati on and may be
used as a base class f or appl ication-defi ned classes.
Al l SystemC integer, i nteger part-select, and i nteger concatenation cl asses shall provi de an assi gnment
operator that accepts an obj ect derived f rom the generic base proxy class template. All SystemC integer
classes shall additionally provi de an overloaded constructor with a single argument that is a constant
ref erence to a generic base proxy object.
NOTEThe generic base proxy class is not i ncl uded i n the col l ecti on of cl asses described by the term SystemC data
types as used in this standard.
7.3 String literals
A string l iteral representati on may be used as the value of a SystemC numeri c or vector type obj ect. It shall
consist of a standard pref ix f ol lowed by a magni tude expressed as one or more digi ts.
The magnitude representation for SystemC i nteger types shall be based on that of C++ i nteger literals.
The magni tude representati on for SystemC vector types shall be based on that of C++ unsi gned i nteger
li teral s.
The magnitude representati on f or SystemC f ixed-point types shall be based on that of C++ f loati ng li teral s
but wi thout the optional fl oating suff ix.
Where al phabetic characters appear i n the pref ix or magnitude representati ons, each indi vi dual character
may be a lowercase letter or an uppercase letter. A string l iteral representation shall not be case sensi ti ve.
The permi tted representations are identi fi ed wi th a symbol from the enumerated type sc_numr ep as
specif ied in Tabl e 5.
An i mplementati on shall provide overl oaded constructors and assi gnment operators that permit the val ue of
any SystemC numeric type or vector to be set by a character string havi ng one of the pref ixes specif ied in
Table 5. The character + or - may optionally be placed before the prefix for decimal and sign &
magnitude formats to indicate polarity. The prefix shall be foll owed by an unsi gned i nteger value, except in
the cases of the bi nary, octal, and hexadeci mal formats, where the prefix shall be followed by a twos
complement value expressed as a bi nary, octal , or hexadeci mal i nteger, respecti vely. An i mplementati on
shal l sign-extend any i nteger stri ng l iteral used to set the val ue of an obj ect having a l onger word l ength.
The canoni cal signed di gi t representation shall use the character - to represent the bit value 1.
A bit-pattern stri ng (containi ng bit or logic character val ues with no pref ix) may be assigned to a vector. If
the number of characters in the bit-pattern stri ng is less than the vector word length, the string shal l be zero
extended at i ts lef t-hand si de to the vector word length. The result of assi gni ng such a stri ng to a numeric
type is undefi ned.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


200
Copyright 2012 IEEE. All rights reserved.
An instance of a SystemC numeric type, vector, part-select, or concatenati on may be converted to a C++
std::str ing obj ect by call ing itsmember functi on to_str ing. Thesignatureof to_str ing shal l beasfoll ows:
std::stri ngto_stri ng( sc_numrepnumrep , bool with_prefix );
The numrep argument shall be one of the sc_numr ep values given in Table5. The magnitude
representation in a stri ng created from an unsigned i nteger or vector shal l be prefi xed by a single zero,
except where numrep i s SC_DEC. If the wi th_prefi x argument i s true, the prefix correspondi ng to the
numrep valuei n Tabl e5 shal l beappended to theleft-hand sideof theresulting stri ng. Thedefaul t val ueof
wi th_prefi x shal l betrue.
It shal l bean error to call themember functi on to_str ing of al ogi c-vector object if any of itsel ementshave
theval ue'X ' or 'Z '.
The val ue of an i nstance of a si ngle-bi t logic type may be converted to a si ngl e character by cal li ng its
member functi on to_char.
Exampl e:
sc_int<4> I1; // 4-bit si gned integer
I1 = "0b10100"; // 5-bit si gned bi nary literal truncated to 4 bi ts
std::stri ngS1 = I1.to_string(SC_BIN,true); // Thecontents of S1 wil l bethestring "0b0100"
sc_int<10> I2; // 10-bit integer
I2= "0d478"; // Deci mal equi val ent of "0b0111011110"
std::stri ngS2 = I2.to_string(SC_CSD,fal se); // Thecontentsof S2 wil l bethestri ng "1000-000-0"
sc_uint<8> I3; // 8-bit unsignedi nteger
Table 5String literal representation
sc_numr ep Pr efix (not case sensitive) M agnitude for mat
SC_NOBASE implementation-defined implementation-defined
SC_DEC 0d decimal
SC_BIN 0b binary
SC_BIN_US 0bus binary unsigned
SC_BIN_SM 0bsm binary sign & magnitude
SC_OCT 0o octal
SC_OCT_US 0ous octal unsigned
SC_OCT_SM 0osm octal sign & magnitude
SC_HEX 0x hexadecimal
SC_HEX_US 0xus hexadecimal unsigned
SC_HEX_SM 0xsm hexadecimal sign & magnitude
SC_CSD 0csd canonical signed digit
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


201
Copyright 2012 IEEE. All rights reserved.
I 3 = "0x7"; // Zero-extended to 8-bi t val ue "0x07"
std::stri ng S3 = I3.to_string(SC_HEX); // The contents of S3 wil l be the string "0x007"
sc_lv<16> lv; // 16-bit logic vector
lv = "0xff "; // Sign-extended to 16-bit val ue "0xf ff f"
std::stri ng S4 = lv.to_string(SC_HEX); // The contents of S4 wil l be the stri ng "0x0ff ff "
sc_bv<8> bv; // 8-bit bi t vector
bv = "11110000"; // Bit-pattern stri ng
std::stri ng S5 = bv.to_string(SC_BI N); // The contents of S5 wil l be the stri ng "0b011110000"
NOTESystemC data types may provi de addi ti onal overl oaded to_str ing f uncti ons that requi re a di f f erent number of
arguments.
7.4 sc_value_base

7.4.1 Description
Cl ass sc_val ue_base

provides a common base class f or all SystemC l imited-preci si on i ntegers and fi nite-
precision integers. I t provides a set of vi rtual methods that may be call ed by an i mplementati on to perform
concatenation operations.
7.4.2 Class definition
namespace sc_dt {
class sc_val ue_base


{
f ri end cl ass sc_concatr ef

;
pri vate:
virtual void concat_clear _data( bool to_ones=f al se );
virtual bool concat_get_ctr l( i mpl ementati on-defi ned* dst_p , int l ow_i ) const;
virtual bool concat_get_data( i mpl ementati on-defi ned* dst_p , int l ow_i ) const;
virtual uint64 concat_get_uint64() const;
virtual i nt concat_length( bool* xz_present_p=0 ) const;
virtual void concat_set( i nt64 src , i nt low_i );
virtual void concat_set( const sc_si gned& src , int l ow_i );
virtual void concat_set( const sc_unsi gned& src , i nt l ow_i );
virtual void concat_set( ui nt64 src , int low_i );
} ;
} // namespace sc_dt
7.4.3 Constraints on usage
An appli cati on should not create an object of type sc_val ue_base

and shoul d not di rectly call any member


f uncti on i nherited by a derived cl ass from an sc_val ue_base

parent.
I f an appl icati on-def ined cl ass deri ved from the generi c base proxy class templ ate sc_gener ic_base is also
derived f rom sc_val ue_base

, objects of thi s class may be used as arguments to an i nteger concatenati on.


Such a class shal l overri de the vi rtual member f uncti ons of sc_val ue_base

as private members to provide


the concatenation operati ons permi tted f or obj ects of that type.
I t shal l be an error for any member functi on of sc_val ue_base

that i s not overri den i n a derived class to be


cal led for an obj ect of the derived class.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


202
Copyright 2012 IEEE. All rights reserved.
7.4.4 Member functions
virtual void concat_clear _data( bool to_ones=f al se );
Member f unction concat_clear _data shal l set every bit in the sc_val ue_base

object to the state


provided by the argument.
virtual bool concat_get_ctr l( i mpl ementati on-defi ned* dst_p , int l ow_i ) const;
Member f unction concat_get_ctr l shal l copy control data to the packed-array given as the f irst
argument, starti ng at the bi t posi ti on wi thi n the packed-array gi ven by the second argument. The
return val ue shal l always be false. The type of the f irst argument shall be a poi nter to an unsi gned
integral type.
virtual bool concat_get_data( i mpl ementati on-defi ned* dst_p , int l ow_i ) const;
Member functi on concat_get_data shall copy data to the packed-array given as the fi rst argument,
starting at the bi t posi tion wi thin the packed-array gi ven by the second argument. The return val ue
shal l be true i f the data i s non-zero; otherwise, i t shall be false. The type of the fi rst argument shall
be a pointer to an unsigned i ntegral type.
virtual uint64 concat_get_uint64() const;
Member function concat_get_uint64 shal l return the value of the sc_val ue_base

object as a C++
unsi gned integer havi ng a word length of exactl y 64-bi ts.
virtual int concat_length( bool* xz_present_p=0 ) const;
Member f unction concat_length shal l return the number of bi ts in the sc_val ue_base

object. The
val ue of the obj ect associ ated wi th the optional argument shal l be set to true if any bits have the
val ue ' X' ' or ' Z' .
virtual void concat_set( i nt64 src , i nt low_i );
virtual void concat_set( const sc_si gned& src , i nt l ow_i );
virtual void concat_set( const sc_unsi gned& src , i nt l ow_i );
virtual void concat_set( ui nt64 src , int low_i );
Member functi on concat_set shall set the value of the sc_val ue_base

obj ect to the bi t-pattern of the


integer given by the f irst argument. The bi t-pattern shall be read as a contiguous sequence of bi ts
starting at the position gi ven by the second argument.
7.5 Limited-precision integer types
7.5.1 Type definitions
The f ol lowi ng type defi ni ti ons are used i n the li mi ted-precision integer type cl asses:
namespace sc_dt {
typedef i mpl ementati on-defi ned int_type;
typedef i mpl ementati on-defi ned uint_type;
typedef i mpl ementati on-defi ned int64;
typedef i mpl ementati on-defi ned uint64;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


203
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_dt
int_type is an implementati on-dependent nati ve C++ integer type. An impl ementation shall provide a
mi nimum representati on size of 64 bits.
uint_type is an i mpl ementation-dependent nati ve C++ unsigned integer type. An impl ementation shal l
provide a minimum representati on size of 64 bi ts.
int64 is a nati ve C++ i nteger type havi ng a word l ength of exactl y 64 bits.
uint64 is a nati ve C++ unsi gned integer type havi ng a word length of exactl y 64 bits.
7.5.2 sc_int_base
7.5.2.1 Description
Cl ass sc_int_base represents a l imi ted word-length i nteger. The word length i s speci fi ed by a constructor
argument or, by default, by the sc_length_context object currentl y i n scope. The word length of an
sc_int_base obj ect shall be f ixed duri ng i nstantiati on and shal l not subsequentl y be changed.
The integer value shal l be hel d in an impl ementation-dependent native C++ integer type. A mini mum
representation si ze of 64 bits is required.
sc_int_base is the base cl ass f or the sc_int class template.
7.5.2.2 Class definition
namespace sc_dt {
class sc_int_base
: publi c sc_val ue_base

{
f ri end cl ass sc_ui nt_bi tr ef_r

;
f ri end cl ass sc_ui nt_bi tr ef

;
f ri end cl ass sc_ui nt_subref_r

;
f ri end cl ass sc_ui nt_subref

;
publ ic:
// Constructors
expl icit sc_int_base( i nt w = sc_l ength_param().len() );
sc_int_base( i nt_type v , i nt w );
sc_int_base( const sc_int_base& a );
templ ate< typename T >
expl icit sc_int_base( const sc_generi c_base<T>& a );
expl icit sc_int_base( const sc_i nt_subref_r

& a );
expl icit sc_int_base( const sc_si gned& a );
expl icit sc_int_base( const sc_unsi gned& a );
expl icit sc_int_base( const sc_bv_base& v );
expl icit sc_int_base( const sc_lv_base& v );
expl icit sc_int_base( const sc_ui nt_subref_r

& v );
expl icit sc_int_base( const sc_si gned_subr ef_r

& v );
expl icit sc_int_base( const sc_unsi gned_subref_r

& v );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


204
Copyright 2012 IEEE. All rights reserved.
// Destructor
~sc_int_base();
// Assi gnment operators
sc_i nt_base& oper ator = ( i nt_type v );
sc_i nt_base& oper ator = ( const sc_int_base& a );
sc_i nt_base& oper ator = ( const sc_i nt_subref_r

& a );
templ ate<cl ass T>
sc_i nt_base& oper ator = ( const sc_generi c_base<T>& a );
sc_i nt_base& oper ator = ( const sc_si gned& a );
sc_i nt_base& oper ator = ( const sc_unsigned& a );
sc_i nt_base& oper ator = ( const sc_fxval& a );
sc_i nt_base& oper ator = ( const sc_fxval_fast& a );
sc_i nt_base& oper ator = ( const sc_fxnum& a );
sc_i nt_base& oper ator = ( const sc_fxnum_fast& a );
sc_i nt_base& oper ator = ( const sc_bv_base& a );
sc_i nt_base& oper ator = ( const sc_lv_base& a );
sc_i nt_base& oper ator = ( const char* a );
sc_i nt_base& oper ator = ( unsigned long a );
sc_i nt_base& oper ator = ( l ong a );
sc_i nt_base& oper ator = ( unsigned int a );
sc_i nt_base& oper ator = ( i nt a );
sc_i nt_base& oper ator = ( ui nt64 a );
sc_i nt_base& oper ator = ( double a );
// Prefi x and postf ix increment and decrement operators
sc_i nt_base& oper ator ++ (); // Prefi x
const sc_i nt_base oper ator ++ ( i nt ); // Postf ix
sc_i nt_base& oper ator-- (); // Prefi x
const sc_i nt_base oper ator-- ( i nt ); // Postf ix
// Bit selecti on
sc_i nt_bi tr ef

oper ator [] ( i nt i );
sc_i nt_bi tr ef_r

oper ator [] ( i nt i ) const;


// Part selection
sc_i nt_subref

oper ator () ( i nt left , int right );


sc_i nt_subref_r

oper ator () ( i nt left , int right ) const;


sc_i nt_subref

r ange( i nt l ef t , int right );


sc_i nt_subref_r

r ange( i nt lef t , int right ) const;


// Capacity
int length() const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Impl icit conversi on to int_type
oper ator int_type() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


205
Copyright 2012 IEEE. All rights reserved.
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
} ;
} // namespace sc_dt
7.5.2.3 Constraints on usage
The word length of an sc_int_base object shall not be greater than the maxi mum size of the integer
representation used to hol d i ts val ue.
7.5.2.4 Constructors
expl icit sc_int_base( i nt w = sc_length_param().len() );
Constructor sc_int_base shall create an object of word l ength speci fi ed by w. I t is the def aul t
constructor when w i s not specif ied (in whi ch case i ts value shal l be set by the current l ength
context). The i niti al val ue of the obj ect shal l be 0.
sc_int_base( i nt_type v , i nt w );
Constructor sc_int_base shal l create an obj ect of word l ength specif i ed by w wi th ini ti al val ue
specif ied by v. Truncation of most signi fi cant bits shall occur i f the val ue cannot be represented i n
the specif ied word l ength.
templ ate< cl ass T >
sc_int_base( const sc_generi c_base<T>& a );
Constructor sc_int_base shal l create an sc_int_base object wi th a word length matching the
constructor argument. The constructor shal l set the i ni ti al val ue of the object to the val ue returned
f rom the member functi on to_int64 of the constructor argument.
The other constructors shal l create an sc_int_base object whose si ze and value matches that of the
argument. The size of the argument shall not be greater than the maximum word l ength of an sc_int_base
object.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


206
Copyright 2012 IEEE. All rights reserved.
7.5.2.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_int_base, usi ng truncation or si gn-extension as descri bed in 7.2.1.
7.5.2.6 Implicit type conversion
oper ator int_type() const;
Operator int_type can be used f or impl icit type conversi on from sc_int_base to the native C++
integer representati on.
NOTE 1This operator enables the use of standard C++ bi twi se l ogi cal and ari thmeti c operators wi th
sc_int_base obj ects.
NOTE 2This operator is used by the C++ output stream operator and by the member f uncti ons of other data
type cl asses that are not expl i ci tl y overl oad f or sc_int_base.
7.5.2.7 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref ix ) const;
Member function to_str ing shal l perf orm the conversion to an std::str ing, as described in 7.2.11.
Call ing the to_str ing f uncti on with a single argument is equi valent to call ing the to_str ing f uncti on
wi th two arguments where the second argument is true. Cal li ng the to_str ing functi on with no
arguments is equival ent to cal li ng the to_str ing f unction with two arguments, where the fi rst
argument is SC_DEC and the second argument is true.
7.5.2.8 Arithmetic, bitwise, and comparison operators
Operati ons specif ied i n Table 6 are permitted. The foll owing appl ies:
n represents an obj ect of type sc_int_base.
i represents an obj ect of integer type int_type.
The arguments of the comparison operators may al so be of any other class that i s deri ved from sc_int_base.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


207
Copyright 2012 IEEE. All rights reserved.
Arithmetic and bitwise operati ons permi tted for C++ integer types shal l be permitted for sc_int_base objects
usi ng i mplici t type conversions. The return type of these operations is an impl ementation-dependent C++
integer type.
NOTEAn implementation is required to suppl y overl oaded operators on sc_int_base objects to sati sf y the
requi rements of thi s subclause. I t i s unspeci f i ed whether these operators are members of sc_int_base, gl obal operators,
or provi ded i n some other way.
7.5.2.9 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
Table 6sc_int_base arithmetic, bitwise, and comparison operations
Expr ession Retur n type Oper ation
n += i sc_i nt_base& sc_i nt_base assi gn sum
n -= i sc_i nt_base& sc_i nt_base assi gn di ff erence
n * = i sc_i nt_base& sc_i nt_base assign product
n /= i sc_i nt_base& sc_i nt_base assi gn quoti ent
n %= i sc_i nt_base& sc_i nt_base assi gn remai nder
n & = i sc_i nt_base& sc_i nt_base assi gn bi twi se and
n |= i sc_i nt_base& sc_i nt_base assi gn bi twi se or
n ^= i sc_i nt_base& sc_i nt_base assi gn bitwi se excl usi ve or
n<<= i sc_i nt_base& sc_i nt_base assi gn l eft-shi f t
n >>= i sc_i nt_base& sc_i nt_base assi gn ri ght-shi ft
n == n bool test equal
n ! = n bool test not equal
n < n bool test l ess than
n <= n bool test l ess than or equal
n > n bool test greater than
n >= n bool test greater than or equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


208
Copyright 2012 IEEE. All rights reserved.
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.5.3 sc_uint_base
7.5.3.1 Description
Cl ass sc_uint_baserepresents a l imited word-l ength unsi gned i nteger. The word l ength shall be speci fied by
a constructor argument or, by default, by the sc_length_context object currentl y in scope. The word length
of an sc_uint_base obj ect shall be f ixed duri ng i nstantiati on and shal l not subsequentl y be changed.
The i nteger val ue shal l be hel d i n an impl ementation-dependent nati ve C++ unsi gned integer type. A
mi nimum representation size of 64 bits i s required.
sc_uint_base is the base class f or the sc_uint class template.
7.5.3.2 Class definition
namespace sc_dt {
class sc_uint_base
: publi c sc_val ue_base

{
f ri end cl ass sc_ui nt_bi tr ef_r

;
f ri end cl ass sc_ui nt_bi tr ef

;
f ri end cl ass sc_ui nt_subref_r

;
f ri end cl ass sc_ui nt_subref

;
publ ic:
// Constructors
expl icit sc_uint_base( i nt w = sc_l ength_param().len() );
sc_uint_base( ui nt_type v , int w );
sc_uint_base( const sc_uint_base& a );
expl icit sc_uint_base( const sc_ui nt_subref_r

& a );
templ ate <class T>
expl icit sc_uint_base( const sc_generi c_base<T>& a );
expl icit sc_uint_base( const sc_bv_base& v );
expl icit sc_uint_base( const sc_lv_base& v );
expl icit sc_uint_base( const sc_i nt_subref_r

& v );
expl icit sc_uint_base( const sc_si gned_subr ef_r

& v );
expl icit sc_uint_base( const sc_unsi gned_subref_r

& v );
expl icit sc_uint_base( const sc_si gned& a );
expl icit sc_uint_base( const sc_unsigned& a );
// Destructor
~sc_uint_base();
// Assi gnment operators
sc_uint_base& oper ator = ( ui nt_type v );
sc_uint_base& oper ator = ( const sc_uint_base& a );
sc_uint_base& oper ator = ( const sc_ui nt_subref_r

& a );
templ ate <class T>
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


209
Copyright 2012 IEEE. All rights reserved.
sc_uint_base& oper ator = ( const sc_generi c_base<T>& a );
sc_uint_base& oper ator = ( const sc_si gned& a );
sc_uint_base& oper ator = ( const sc_unsigned& a );
sc_uint_base& oper ator = ( const sc_fxval& a );
sc_uint_base& oper ator = ( const sc_fxval _fast& a );
sc_uint_base& oper ator = ( const sc_fxnum& a );
sc_uint_base& oper ator = ( const sc_fxnum_fast& a );
sc_uint_base& oper ator = ( const sc_bv_base& a );
sc_uint_base& oper ator = ( const sc_lv_base& a );
sc_uint_base& oper ator = ( const char* a );
sc_uint_base& oper ator = ( unsigned long a );
sc_uint_base& oper ator = ( l ong a );
sc_uint_base& oper ator = ( unsigned int a );
sc_uint_base& oper ator = ( i nt a );
sc_uint_base& oper ator = ( i nt64 a );
sc_uint_base& oper ator = ( double a );
// Prefi x and postf ix increment and decrement operators
sc_uint_base& oper ator ++ (); // Prefi x
const sc_ui nt_base oper ator ++ ( i nt ); // Postfi x
sc_uint_base& oper ator-- (); // Prefi x
const sc_ui nt_base oper ator-- ( i nt ); // Postfi x
// Bit selecti on
sc_ui nt_bi tr ef

oper ator [] ( i nt i );
sc_ui nt_bi tr ef_r

oper ator [] ( i nt i ) const;


// Part selection
sc_ui nt_subref

oper ator () ( i nt l ef t, int right );


sc_ui nt_subref_r

oper ator () ( i nt lef t, int right ) const;


sc_ui nt_subref

r ange( i nt lef t, int ri ght );


sc_ui nt_subref_r

r ange( i nt lef t, int ri ght ) const;


// Capacity
int length() const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Impl icit conversi on to ui nt_type
operator uint_type() const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


210
Copyright 2012 IEEE. All rights reserved.
doubl e to_double() const;
// Expli ci t conversi on to character string
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
} ;
} // namespace sc_dt
7.5.3.3 Constraints on usage
The word l ength of an sc_uint_base object shall not be greater than the maxi mum size of the unsi gned
integer representati on used to hold its value.
7.5.3.4 Constructors
expl icit sc_uint_base( i nt w = sc_l ength_param().len() );
Constructor sc_uint_base shal l create an object of word l ength speci fi ed by w. This i s the def aul t
constructor when w is not specif ied (i n which case its val ue is set by the current length context). The
ini ti al val ue of the obj ect shal l be 0.
sc_uint_base( ui nt_type v , int w );
Constructor sc_uint_base shal l create an object of word length specif ied by w wi th i niti al value
specif ied by v. Truncation of most signi fi cant bits shall occur i f the val ue cannot be represented i n
the specif ied word l ength.
templ ate< cl ass T >
sc_uint_base( const sc_generi c_base<T>& a );
Constructor sc_uint_base shal l create an sc_uint_base object wi th a word length matching the
constructor argument. The constructor shal l set the i ni ti al val ue of the object to the val ue returned
f rom the member functi on to_uint64 of the constructor argument.
The other constructors shal l create an sc_uint_base object whose si ze and value matches that of the
argument. The size of the argument shall not be greater than the maximum word l ength of an sc_uint_base
object.
7.5.3.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_uint_base, usi ng truncation or si gn-extensi on as descri bed i n 7.2.1.
7.5.3.6 Implicit type conversion
operator uint_type() const;
Operator uint_type can be used f or impl ici t type conversion from sc_uint_base to the native C++
unsi gned integer representation.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


211
Copyright 2012 IEEE. All rights reserved.
NOTE 1This operator enables the use of standard C++ bi twi se l ogi cal and ari thmeti c operators wi th
sc_uint_base obj ects.
NOTE 2This operator is used by the C++ output stream operator and by the member f uncti ons of other data
type cl asses that are not expl i ci tl y overl oad f or sc_uint_base.
7.5.3.7 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
Member function to_str ing shal l perf orm the conversion to an std::str ing, as described in 7.2.11.
Call ing the to_str ing f uncti on with a single argument is equi valent to call ing the to_str ing f uncti on
wi th two arguments, where the second argument is true. Call ing the to_str ing f unction wi th no
arguments is equival ent to cal li ng the to_str ing f unction with two arguments, where the fi rst
argument is SC_DEC and the second argument is true.
7.5.3.8 Arithmetic, bitwise, and comparison operators
Operati ons specif ied i n Table 7 are permitted. The foll owing appl ies:
U represents an obj ect of type sc_uint_base.
u represents an obj ect of integer type uint_type.
The arguments of the compari son operators may also be of any other class that is deri ved from
sc_uint_base.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


212
Copyright 2012 IEEE. All rights reserved.
Arithmetic and bi twi se operati ons permi tted f or C++ i nteger types shal l be permi tted f or sc_uint_base
objects using impl ici t type conversions. The return type of these operations i s an impl ementation-dependent
C++ integer type.
NOTEAn implementation is required to suppl y overl oaded operators on sc_uint_base obj ects to sati sf y the
requi rements of thi s subcl ause. I t i s unspeci f i ed whether these operators are members of sc_uint_base, global operators,
or provi ded i n some other way.
7.5.3.9 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
Table 7sc_uint_base arithmetic, bitwise, and comparison operations
Expr ession Retur n type Oper ation
U += u sc_ui nt_base& sc_ui nt_base assi gn sum
U -= u sc_ui nt_base& sc_ui nt_base assi gn di f f erence
U * = u sc_ui nt_base& sc_ui nt_base assi gn product
U /= u sc_ui nt_base& sc_ui nt_base assi gn quoti ent
U %= u sc_ui nt_base& sc_ui nt_base assi gn remai nder
U & = u sc_ui nt_base& sc_ui nt_base assi gn bi twi se and
U |= u sc_ui nt_base& sc_ui nt_base assi gn bi twi se or
U ^= u sc_ui nt_base& sc_ui nt_base assi gn bitwi se exclusi ve or
U <<= u sc_ui nt_base& sc_ui nt_base assi gn l ef t-shi f t
U >>= u sc_ui nt_base& sc_ui nt_base assi gn right-shi f t
U == U bool test equal
U ! = U bool test not equal
U < U bool test l ess than
U <= U bool test l ess than or equal
U > U bool test greater than
U >= U bool test greater than or equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


213
Copyright 2012 IEEE. All rights reserved.
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.5.4 sc_int
7.5.4.1 Description
Class templ ate sc_int represents a limited word-length signed i nteger. The word length shall be specif ied by
a template argument.
Any publi c member functi ons of the base cl ass sc_int_base that are overridden in class sc_int shall have the
same behavior in the two cl asses. Any publ ic member f uncti ons of the base class not overridden i n this way
shall be publi cl y i nherited by cl ass sc_int.
7.5.4.2 Class definition
namespace sc_dt {
templ ate <i nt W>
class sc_int
: publi c sc_i nt_base
{
publ ic:
// Constructors
sc_int();
sc_int( i nt_type v );
sc_int( const sc_int<W>& a );
sc_int( const sc_int_base& a );
sc_int( const sc_i nt_subref_r

& a );
templ ate <class T>
sc_int( const sc_generi c_base<T>& a );
sc_int( const sc_si gned& a );
sc_int( const sc_unsigned& a );
expl icit sc_int( const sc_fxval& a );
expl icit sc_int( const sc_fxval_fast& a );
expl icit sc_int( const sc_fxnum& a );
expl icit sc_int( const sc_fxnum_fast& a );
sc_int( const sc_bv_base& a );
sc_int( const sc_lv_base& a );
sc_int( const char* a );
sc_int( unsigned long a );
sc_int( l ong a );
sc_int( unsigned i nt a );
sc_int( i nt a );
sc_int( ui nt64 a );
sc_int( double a );
// Assi gnment operators
sc_i nt<W>& oper ator = ( i nt_type v );
sc_i nt<W>& oper ator = ( const sc_int_base& a );
sc_int<W>& oper ator = ( const sc_i nt_subref_r

& a );
sc_i nt<W>& oper ator = ( const sc_int<W>& a );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


214
Copyright 2012 IEEE. All rights reserved.
templ ate <class T>
sc_i nt<W>& oper ator = ( const sc_generi c_base<T>& a );
sc_i nt<W>& oper ator = ( const sc_si gned& a );
sc_i nt<W>& oper ator = ( const sc_unsigned& a );
sc_i nt<W>& oper ator = ( const sc_fxval& a );
sc_i nt<W>& oper ator = ( const sc_fxval _fast& a );
sc_i nt<W>& oper ator = ( const sc_fxnum& a );
sc_i nt<W>& oper ator = ( const sc_fxnum_fast& a );
sc_i nt<W>& oper ator = ( const sc_bv_base& a );
sc_i nt<W>& oper ator = ( const sc_lv_base& a );
sc_i nt<W>& oper ator = ( const char* a );
sc_i nt<W>& oper ator = ( unsigned long a );
sc_i nt<W>& oper ator = ( l ong a );
sc_i nt<W>& oper ator = ( unsigned int a );
sc_i nt<W>& oper ator = ( i nt a );
sc_i nt<W>& oper ator = ( ui nt64 a );
sc_i nt<W>& oper ator = ( double a );
// Prefi x and postf ix increment and decrement operators
sc_i nt<W>& oper ator ++ (); // Prefi x
const sc_i nt<W> oper ator ++ ( i nt ); // Postf ix
sc_i nt<W>& oper ator-- (); // Prefi x
const sc_i nt<W> oper ator-- ( i nt ); // Postf ix
} ;
} // namespace sc_dt
7.5.4.3 Constraints on usage
The word l ength of an sc_int object shall not be greater than the maxi mum word l ength of an sc_int_base.
7.5.4.4 Constructors
sc_int();
Default constructor sc_int shal l create an sc_int object of word length specif ied by the templ ate
argument W. The i ni ti al val ue of the object shal l be 0.
templ ate< cl ass T >
sc_int( const sc_generi c_base<T>& a );
Constructor sc_int shall create an sc_int obj ect of word l ength speci f ied by the template argument.
The constructor shal l set the ini ti al value of the object to the val ue returned f rom the member
f uncti on to_int64 of the constructor argument.
The other constructors shall create an sc_int object of word length specif ied by the template argument W
and value corresponding to the i nteger magni tude of the constructor argument. If the word length of the
specif ied i nitial value di ffers from the template argument, truncati on or si gn-extension shall be used as
descri bed in 7.2.1.
7.5.4.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_int, usi ng truncation or si gn-extension as descri bed in 7.2.1.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


215
Copyright 2012 IEEE. All rights reserved.
7.5.4.6 Arithmetic and bitwise operators
Operati ons specif ied i n Table 8 are permitted. The foll owing appl ies:
n represents an obj ect of type sc_int.
i represents an obj ect of integer type int_type.
Arithmetic and bitwise operations permi tted for C++ i nteger types shall be permi tted for sc_int obj ects using
implici t type conversions. The return type of these operations is an impl ementation-dependent C++ i nteger
type.
NOTEAn implementation is required to suppl y overl oaded operators on sc_int objects to sati sf y the requi rements of
thi s subcl ause. It i s unspeci f i ed whether these operators are members of sc_int, gl obal operators, or provi ded i n some
other way.
7.5.5 sc_uint
7.5.5.1 Description
Class template sc_uint represents a limited word-l ength unsi gned i nteger. The word l ength shall be
specif ied by a template argument. Any publi c member f unctions of the base cl ass sc_uint_base that are
overri dden i n class sc_uint shall have the same behavior i n the two classes. Any publi c member functions of
the base cl ass not overridden i n this way shal l be publi cl y inherited by cl ass sc_uint.
7.5.5.2 Class definition
namespace sc_dt {
templ ate <i nt W>
class sc_uint
Table 8sc_int arithmetic and bitwise operations
Expr ession Retur n type Oper ation
n += i sc_int<W>& sc_int assi gn sum
n -= i sc_i nt<W>& sc_i nt assi gn di ff erence
n * = i sc_i nt<W>& sc_i nt assi gn product
n /= i sc_i nt<W>& sc_i nt assi gn quoti ent
n %= i sc_i nt<W>& sc_i nt assi gn remai nder
n & = i sc_int<W>& sc_int assi gn bi twi se and
n |= i sc_i nt<W>& sc_i nt assi gn bi twi se or
n ^= i sc_i nt<W>& sc_i nt assi gn bi twi se excl usi ve or
n <<= i sc_i nt<W>& sc_i nt assi gn l ef t-shi f t
n >>= i sc_i nt<W>& sc_i nt assi gn ri ght-shi f t
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


216
Copyright 2012 IEEE. All rights reserved.
: publi c sc_ui nt_base
{
publ ic:
// Constructors
sc_uint();
sc_uint( ui nt_type v );
sc_uint( const sc_ui nt<W>& a );
sc_uint( const sc_uint_base& a );
sc_uint( const sc_ui nt_subref_r

& a );
templ ate <class T>
sc_uint( const sc_generi c_base<T>& a );
sc_uint( const sc_si gned& a );
sc_uint( const sc_unsigned& a );
expl icit sc_uint( const sc_fxval& a );
expl icit sc_uint( const sc_fxval _fast& a );
expl icit sc_uint( const sc_fxnum& a );
expl icit sc_uint( const sc_fxnum_fast& a );
sc_uint( const sc_bv_base& a );
sc_uint( const sc_lv_base& a );
sc_uint( const char* a );
sc_uint( unsigned l ong a );
sc_uint( l ong a );
sc_uint( unsigned i nt a );
sc_uint( i nt a );
sc_uint( i nt64 a );
sc_uint( double a );
// Assi gnment operators
sc_uint<W>& oper ator = ( ui nt_type v );
sc_uint<W>& oper ator = ( const sc_uint_base& a );
sc_uint<W>& oper ator = ( const sc_ui nt_subref_r

& a );
sc_uint<W>& oper ator = ( const sc_ui nt<W>& a );
templ ate <class T>
sc_uint<W>& oper ator = ( const sc_generi c_base<T>& a );
sc_uint<W>& oper ator = ( const sc_si gned& a );
sc_uint<W>& oper ator = ( const sc_unsigned& a );
sc_uint<W>& oper ator = ( const sc_fxval & a );
sc_uint<W>& oper ator = ( const sc_fxval_fast& a );
sc_uint<W>& oper ator = ( const sc_fxnum& a );
sc_uint<W>& oper ator = ( const sc_fxnum_fast& a );
sc_uint<W>& oper ator = ( const sc_bv_base& a );
sc_uint<W>& oper ator = ( const sc_lv_base& a );
sc_uint<W>& oper ator = ( const char* a );
sc_uint<W>& oper ator = ( unsigned l ong a );
sc_uint<W>& oper ator = ( l ong a );
sc_uint<W>& oper ator = ( unsigned i nt a );
sc_uint<W>& oper ator = ( i nt a );
sc_uint<W>& oper ator = ( i nt64 a );
sc_uint<W>& oper ator = ( doubl e a );
// Prefi x and postf ix increment and decrement operators
sc_uint<W>& oper ator ++ (); // Prefi x
const sc_ui nt<W> oper ator ++ ( i nt ); // Postfi x
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


217
Copyright 2012 IEEE. All rights reserved.
sc_uint<W>& oper ator-- (); // Pref ix
const sc_uint<W> oper ator-- ( i nt ); // Postfi x
} ;
} // namespace sc_dt
7.5.5.3 Constraints on usage
The word length of an sc_uint object shal l not be greater than the maximum word length of an
sc_uint_base.
7.5.5.4 Constructors
sc_uint();
Default constructor sc_uint shall create an sc_uint obj ect of word l ength specif ied by the template
argument W. The i ni ti al val ue of the object shal l be 0.
templ ate< cl ass T >
sc_uint( const sc_generi c_base<T>& a );
Constructor sc_uint shal l create an sc_uint object of word length specif ied by the template
argument. The constructor shall set the initial val ue of the object to the val ue returned from the
member f uncti on to_uint64 of the constructor argument.
The other constructors shall create an sc_uint obj ect of word length speci fi ed by the templ ate argument W
and value corresponding to the integer magnitude of the constructor argument. If the word length of the
specif ied i nitial value di ffers from the template argument, truncati on or si gn-extension shall be used as
descri bed in 7.2.1.
7.5.5.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to sc_uint. I f the si ze of a data type or string l iteral operand dif fers from the sc_uint
word l ength, truncati on or si gn-extension shall be used as descri bed in 7.2.1.
7.5.5.6 Arithmetic and bitwise operators
Operati ons specif ied i n Table 9 are permitted. The foll owing appl ies:
U represents an obj ect of type sc_uint.
u represents an obj ect of integer type uint_type.
Arithmetic and bitwise operations permi tted f or C++ integer types shal l be permitted for sc_uint objects
usi ng i mplici t type conversions. The return type of these operations is an impl ementation-dependent C++
integer.
NOTEAn implementation is required to suppl y overl oaded operators on sc_uint obj ects to sati sf y the requi rements of
thi s subcl ause. I t i s unspeci fi ed whether these operators are members of sc_uint, gl obal operators, or provi ded i n some
other way.
7.5.6 Bit-selects
7.5.6.1 Description
Class sc_i nt_bi tr ef_r

represents a bit selected from an sc_int_base used as an rval ue.


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


218
Copyright 2012 IEEE. All rights reserved.
Cl ass sc_i nt_bi tr ef

represents a bit selected f rom an sc_int_base used as an l val ue.


Cl ass sc_ui nt_bi tr ef_r

represents a bi t sel ected f rom an sc_uint_base used as an rval ue.


Cl ass sc_ui nt_bi tr ef

represents a bit selected f rom an sc_uint_base used as an l val ue.


7.5.6.2 Class definition
namespace sc_dt {
class sc_i nt_bi tr ef_r

: publi c sc_val ue_base

{
f riend cl ass sc_int_base;
publ ic:
// Copy constructor
sc_i nt_bi tr ef_r

( const sc_i nt_bi tref_r

& a );
// Destructor
virtual ~sc_i nt_bi tr ef_r

();
// Capacity
int length() const;
// Impl icit conversi on to ui nt64
oper ator uint64 () const;
bool oper ator ! () const;
bool oper ator ~ () const;
Table 9sc_uint arithmetic and bitwise operations
Expr ession Retur n type Oper ation
U += u sc_ui nt<W>& sc_ui nt assi gn sum
U -= u sc_ui nt<W>& sc_ui nt assi gn di f f erence
U * = u sc_ui nt<W>& sc_ui nt assi gn product
U /= u sc_ui nt<W>& sc_ui nt assi gn quoti ent
U %= u sc_ui nt<W>& sc_ui nt assi gn remai nder
U & = u sc_ui nt<W>& sc_ui nt assi gn bitwi se and
U |= u sc_ui nt<W>& sc_ui nt assi gn bi twi se or
U ^= u sc_ui nt<W>& sc_ui nt assi gn bitwi se excl usi ve or
U <<= u sc_ui nt<W>& sc_ui nt assi gn lef t-shi ft
U >>= u sc_ui nt<W>& sc_ui nt assi gn ri ght-shi f t
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


219
Copyright 2012 IEEE. All rights reserved.
// Expl icit conversions
bool to_bool() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_i nt_bi tr ef_r

();
pri vate:
// Di sabl ed
sc_i nt_bi tr ef_r

& oper ator = ( const sc_i nt_bi tr ef_r

& );
} ;
// -------------------------------------------------------------
class sc_i nt_bi tr ef

: publi c sc_i nt_bi tr ef_r

{
f riend cl ass sc_int_base;
publ ic:
// Copy constructor
sc_i nt_bi tr ef

( const sc_i nt_bi tr ef

& a );
// Assi gnment operators
sc_i nt_bi tr ef

& oper ator = ( const sc_i nt_bi tr ef_r

& b );
sc_i nt_bi tr ef

& oper ator = ( const sc_i nt_bi tr ef

& b );
sc_i nt_bi tr ef

& oper ator = ( bool b );


sc_i nt_bi tr ef

& oper ator & = ( bool b );


sc_i nt_bi tr ef

& oper ator |= ( bool b );


sc_i nt_bi tr ef

& oper ator ^= ( bool b );


// Other methods
void scan( std::i stream& i s = std::ci n );
pri vate:
sc_i nt_bi tr ef

();
} ;
// -------------------------------------------------------------
class sc_ui nt_bi tr ef_r


: publi c sc_val ue_base

{
f riend cl ass sc_ui nt_base;
publ ic:
// Copy constructor
sc_ui nt_bi tr ef_r

( const sc_ui nt_bi tr ef_r

& a );
// Destructor
virtual ~sc_ui nt_bi tr ef_r

();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


220
Copyright 2012 IEEE. All rights reserved.
// Capacity
int length() const;
// Impl icit conversi on to ui nt64
oper ator uint64 () const;
bool oper ator ! () const;
bool oper ator ~ () const;
// Expl icit conversions
bool to_bool() const;
// Other methods
voi d pr int( std::ostream& os = std::cout ) const;
protected:
sc_ui nt_bi tr ef_r

();
pri vate:
// Di sabl ed
sc_ui nt_bi tr ef_r

& oper ator = ( const sc_ui nt_bi tr ef_r

& );
} ;
// -------------------------------------------------------------
class sc_ui nt_bi tr ef

: publi c sc_ui nt_bi tr ef_r

{
f riend cl ass sc_ui nt_base;
publ ic:
// Copy constructor
sc_ui nt_bi tr ef

( const sc_ui nt_bi tr ef

& a );
// Assi gnment operators
sc_ui nt_bi tr ef

& oper ator = ( const sc_ui nt_bi tr ef_r

& b );
sc_ui nt_bi tr ef

& oper ator = ( const sc_ui nt_bi tr ef

& b );
sc_ui nt_bi tr ef

& oper ator = ( bool b );


sc_ui nt_bi tr ef

& oper ator & = ( bool b );


sc_ui nt_bi tr ef

& operator |= ( bool b );


sc_ui nt_bi tr ef

& oper ator ^= ( bool b );


// Other methods
void scan( std::i stream& i s = std::ci n );
pri vate:
sc_ui nt_bi tr ef

();
} ;
} // namespace sc_dt
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


221
Copyright 2012 IEEE. All rights reserved.
7.5.6.3 Constraints on usage
Bi t-select obj ects shall only be created usi ng the bi t-sel ect operators of an sc_int_base or sc_uint_base
object (or an instance of a cl ass derived f rom sc_int_base or sc_uint_base).
An appl ication shall not expli citl y create an i nstance of any bi t-sel ect class.
An appl ication should not decl are a reference or pointer to any bit-sel ect obj ect.
I t is strongly recommended that an appl ication avoi d the use of a bi t-sel ect as the return type of a f unction
because the l if etime of the obj ect to whi ch the bi t-select ref ers may not extend beyond the f uncti on return
statement.
Exampl e:
sc_dt::sc_i nt_bitref get_bit_n(sc_int_base i, i nt n) {
return i[ n] ; // Unsaf e: returned bit-sel ect references local variable
}
7.5.6.4 Assignment operators
Overl oaded assi gnment operators f or the lvalue bi t-sel ects shall provide conversi on from bool val ues.
Assi gnment operators f or rvalue bi t-sel ects shall be declared as pri vate to prevent their use by an
appl ication.
7.5.6.5 Implicit type conversion
oper ator uint64() const;
Operator uint64 can be used for impl icit type conversi on from a bi t-select to the nati ve C++
unsi gned i nteger having exactly 64 bits. If the sel ected bi t has the value ' 1' (true), the conversi on
shal l return the value 1; otherwi se, it shall return 0.
bool oper ator ! () const;
bool oper ator ~ () const;
oper ator ! and oper ator ~ shall return a C++ bool val ue that is the i nverse of the sel ected bit.
7.5.6.6 Other member functions
void scan( std::i stream& i s = std::ci n );
Member f unction scan shal l set the value of the bit referenced by an lvalue bit-sel ect. The val ue
shal l correspond to the C++ bool val ue obtai ned by reading the next formatted character string from
the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member function pr int shal l print the value of the bi t referenced by the bi t-select to the speci fi ed
output stream (see 7.2.10). The formatti ng shal l be i mplementati on-defi ned but shall be equi val ent
to pri nti ng the val ue returned by member functi on to_bool.
int length() const;
Member f uncti on length shall unconditi onal ly return a word l ength of 1 (see 7.2.4).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


222
Copyright 2012 IEEE. All rights reserved.
7.5.7 Part-selects
7.5.7.1 Description
Class sc_i nt_subref_r

represents a si gned integer part-select from an sc_int_base used as an rval ue.


Cl ass sc_i nt_subref

represents a si gned integer part-sel ect f rom an sc_int_base used as an l val ue.
Class sc_ui nt_subr ef_r

represents an unsigned i nteger part-select f rom an sc_uint_base used as an rval ue.


Cl ass sc_ui nt_subref

represents an unsigned i nteger part-select f rom an sc_uint_base used as an l val ue.


7.5.7.2 Class definition
namespace sc_dt {
class sc_i nt_subref_r

{
f riend cl ass sc_int_base;
f ri end cl ass sc_i nt_subref

;
publ ic:
// Copy constructor
sc_i nt_subref_r

( const sc_i nt_subref_r

& a );
// Destructor
virtual ~sc_i nt_subref_r

();
// Capacity
int length() const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Impl icit conversi on to ui nt_type
oper ator uint_type() const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


223
Copyright 2012 IEEE. All rights reserved.
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_i nt_subref_r

();
pri vate:
// Di sabl ed
sc_i nt_subref_r

& oper ator = ( const sc_i nt_subref_r

& );
} ;
// -------------------------------------------------------------
class sc_i nt_subref

: publi c sc_i nt_subref_r

{
f riend cl ass sc_int_base;
publ ic:
// Copy constructor
sc_i nt_subref

( const sc_i nt_subref

& a );
// Assi gnment operators
sc_i nt_subref

& oper ator = ( i nt_type v );


sc_i nt_subref

& oper ator = ( const sc_int_base& a );


sc_i nt_subref

& oper ator = ( const sc_i nt_subref_r

& a );
sc_i nt_subref

& oper ator = ( const sc_i nt_subref

& a );
templ ate< cl ass T >
sc_i nt_subref

& oper ator = ( const sc_generi c_base<T>& a );


sc_i nt_subref

& oper ator = ( const char* a );


sc_i nt_subref

& oper ator = ( unsigned long a );


sc_i nt_subref

& oper ator = ( l ong a );


sc_i nt_subref

& oper ator = ( unsigned int a );


sc_i nt_subref

& oper ator = ( i nt a );


sc_i nt_subref

& oper ator = ( ui nt64 a );


sc_i nt_subref

& oper ator = ( double a );


sc_i nt_subref

& oper ator = ( const sc_si gned& );


sc_i nt_subref

& oper ator = ( const sc_unsigned& );


sc_i nt_subref

& oper ator = ( const sc_bv_base& );


sc_i nt_subref

& oper ator = ( const sc_lv_base& );


// Other methods
void scan( std::i stream& i s = std::ci n );
protected:
sc_i nt_subref

();
} ;
// -------------------------------------------------------------
class sc_ui nt_subref_r

{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


224
Copyright 2012 IEEE. All rights reserved.
f riend cl ass sc_ui nt_base;
f ri end cl ass sc_ui nt_subref

;
publ ic:
// Copy constructor
sc_ui nt_subref_r

( const sc_ui nt_subref_r

& a );
// Destructor
virtual ~sc_uint_subref_r ();
// Capacity
int length() const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Impl icit conversi on to ui nt_type
operator uint_type() const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_ui nt_subref_r

();
pri vate:
// Di sabl ed
sc_uint_subref_r& oper ator = ( const sc_uint_subref_r& );
} ;
// -------------------------------------------------------------
class sc_ui nt_subref

: publi c sc_ui nt_subref_r

{
f riend cl ass sc_ui nt_base;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


225
Copyright 2012 IEEE. All rights reserved.
publ ic:
// Copy constructor
sc_ui nt_subref

( const sc_ui nt_subref

& a );
// Assi gnment operators
sc_ui nt_subref

& oper ator = ( uint_type v );


sc_ui nt_subref

& oper ator = ( const sc_ui nt_base& a );


sc_ui nt_subref

& oper ator = ( const sc_ui nt_subref _r& a );


sc_ui nt_subref

& oper ator = ( const sc_ui nt_subref & a );


templ ate<cl ass T>
sc_ui nt_subref

& oper ator = ( const sc_generic_base<T>& a );


sc_ui nt_subref

& oper ator = ( const char* a );


sc_ui nt_subref

& oper ator = ( unsi gned long a );


sc_ui nt_subref

& oper ator = ( l ong a );


sc_ui nt_subref

& oper ator = ( unsi gned int a );


sc_ui nt_subref

& oper ator = ( i nt a );


sc_ui nt_subref

& oper ator = ( i nt64 a );


sc_ui nt_subref

& oper ator = ( doubl e a );


sc_ui nt_subref

& oper ator = ( const sc_si gned& );


sc_ui nt_subref

& oper ator = ( const sc_unsigned& );


sc_ui nt_subref

& oper ator = ( const sc_bv_base& );


sc_ui nt_subref

& oper ator = ( const sc_lv_base& );


// Other methods
void scan( std::i stream& i s = std::ci n );
protected:
sc_ui nt_subref

();
} ;
} // namespace sc_dt
7.5.7.3 Constraints on usage
I nteger part-select objects shall only be created using the part-sel ect operators of an sc_int_base or
sc_uint_base object (or an i nstance of a cl ass deri ved f rom sc_int_base or sc_uint_base), as descri bed in
7.2.6.
An appl ication shall not expli citl y create an instance of any integer part-sel ect cl ass.
An appl ication should not declare a reference or pointer to any i nteger part-select object.
I t shal l be an error if the l ef t-hand i ndex of a li mited-preci si on integer part-select i s less than the ri ght-hand
index.
I t i s strongly recommended that an appli cation avoi d the use of a part-select as the return type of a functi on
because the li feti me of the obj ect to which the part-select refers may not extend beyond the functi on return
statement.
Exampl e:
sc_dt::sc_i nt_subref get_byte(sc_int_base i b, i nt pos) {
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


226
Copyright 2012 IEEE. All rights reserved.
return ib(pos+7,pos); // Unsafe: returned part-select ref erences l ocal vari abl e
}
7.5.7.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to lval ue integer part-sel ects. I f the size of a data type or stri ng li teral operand dif fers
f rom the i nteger part-sel ect word l ength, truncati on, zero-extensi on, or si gn-extension shall be used as
descri bed in 7.2.1.
Assi gnment operators for rvalue integer part-selects shal l be decl ared as pri vate to prevent their use by an
appl ication.
7.5.7.5 Implicit type conversion
sc_i nt_subref_r

::oper ator uint_type() const;


sc_ui nt_subref_r

::oper ator uint_type() const;


oper ator int_type and oper ator uint_type can be used f or impl icit type conversi on from i nteger
part-sel ects to the nati ve C++ unsi gned integer representation.
NOTE 1These operators enable the use of standard C++ bi twi se l ogi cal and ari thmeti c operators wi th i nteger
part-sel ect obj ects.
NOTE 2These operators are used by the C++ output stream operator and by member functi ons of other data
type cl asses that are not expl i ci tly overl oad f or i nteger part-sel ects.
7.5.7.6 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
Member function to_str ing shal l perf orm the conversion to an std::str ing, as described in 7.2.11.
Call ing the to_str ing f uncti on with a single argument is equi valent to call ing the to_str ing f uncti on
wi th two arguments, where the second argument is true. Call ing the to_str ing f unction wi th no
arguments is equival ent to cal li ng the to_str ing f unction with two arguments, where the fi rst
argument is SC_DEC and the second argument is true.
7.5.7.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member function scan shal l set the values of the bi ts ref erenced by an lvalue part-select by reading
the next formatted character string from the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member functi on pr int shall print the val ues of the bi ts referenced by the part-sel ect to the specif ied
output stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length of the part-select (see 7.2.4).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


227
Copyright 2012 IEEE. All rights reserved.
7.6 Finite-precision integer types
7.6.1 Type definitions
The f ol lowi ng type def i ni ti ons are used i n the f ini te-precision integer type classes:
namespace sc_dt{
typedef i mpl ementati on-defi ned int64;
typedef i mpl ementati on-defi ned uint64;
} // namespace sc_dt
int64 is a nati ve C++ i nteger type havi ng a word l ength of exactl y 64 bits.
uint64 is a nati ve C++ unsi gned integer type havi ng a word length of exactl y 64 bits.
7.6.2 Constraints on usage
Overl oaded ari thmeti c and comparison operators all ow fi ni te-preci si on integer objects to be used in
expressions f ol lowi ng simi lar but not identi cal rules to standard C++ i nteger types. The di ff erences f rom the
standard C++ i nteger operator behavi or are the fol lowing:
a) Where one operand i s unsi gned and the other is si gned, the unsi gned operand shal l be converted to
signed and the return type shall be signed.
b) The return type of a subtraction shall al ways be signed.
c) The word l ength of the return type of an arithmeti c operator shall depend only on the nature of the
operation and on the word length of its operands.
d) A f loating-poi nt variable or l iteral shal l not be di rectl y used as an operand. It should fi rst be
converted to an appropriate si gned or unsi gned integer type.
7.6.3 sc_signed
7.6.3.1 Description
Cl ass sc_signed represents a fini te word-length i nteger. The word l ength shall be speci fi ed by a constructor
argument or, by default, by the length context obj ect currentl y in scope. The word length of an sc_signed
object shall be f ixed duri ng i nstantiati on and shal l not subsequentl y be changed.
The integer value shal l be stored with a fi ni te preci sion determi ned by the speci fi ed word l ength. The
precision shall not depend on the l imited resoluti on of any standard C++ integer type.
sc_signed is the base cl ass for the sc_bigint class templ ate.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


228
Copyright 2012 IEEE. All rights reserved.
7.6.3.2 Class definition
namespace sc_dt {
class sc_signed
: publi c sc_val ue_base

{
f ri end cl ass sc_concatr ef

;
f ri end cl ass sc_si gned_bi tref_r

;
f ri end cl ass sc_si gned_bi tref

;
f ri end cl ass sc_si gned_subr ef_r

;
f ri end cl ass sc_si gned_subr ef

;
f riend cl ass sc_unsigned;
f riend cl ass sc_unsigned_subref;
publ ic:
// Constructors
expl icit sc_signed( i nt nb = sc_length_param().l en() );
sc_signed( const sc_si gned& v );
sc_signed( const sc_unsigned& v );
templ ate<cl ass T>
expl icit sc_signed( const sc_generi c_base<T>& v );
expl icit sc_signed( const sc_bv_base& v );
expl icit sc_signed( const sc_lv_base& v );
expl icit sc_signed( const sc_int_subref_r& v );
expl icit sc_signed( const sc_uint_subref _r& v );
expl icit sc_signed( const sc_si gned_subref _r& v );
expl icit sc_signed( const sc_unsigned_subref_r& v );
// Assi gnment operators
sc_signed& oper ator = ( const sc_si gned& v );
sc_signed& oper ator = ( const sc_si gned_subr ef_r

& a );
templ ate< cl ass T >
sc_signed& oper ator = ( const sc_generi c_base<T>& a );
sc_signed& oper ator = ( const sc_unsigned& v );
sc_signed& oper ator = ( const sc_unsi gned_subref_r

& a );
sc_signed& oper ator = ( const char* v );
sc_signed& oper ator = ( i nt64 v );
sc_signed& oper ator = ( ui nt64 v );
sc_signed& oper ator = ( l ong v );
sc_signed& oper ator = ( unsigned long v );
sc_signed& oper ator = ( i nt v );
sc_signed& oper ator = ( unsigned int v );
sc_signed& oper ator = ( double v );
sc_signed& oper ator = ( const sc_int_base& v );
sc_signed& oper ator = ( const sc_ui nt_base& v );
sc_signed& oper ator = ( const sc_bv_base& );
sc_signed& oper ator = ( const sc_lv_base& );
sc_signed& oper ator = ( const sc_fxval & );
sc_signed& oper ator = ( const sc_fxval _fast& );
sc_signed& oper ator = ( const sc_fxnum& );
sc_signed& oper ator = ( const sc_fxnum_fast& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


229
Copyright 2012 IEEE. All rights reserved.
// Destructor
~sc_signed();
// Increment operators.
sc_signed& oper ator ++ ();
const sc_signed oper ator ++ ( i nt );
// Decrement operators.
sc_signed& oper ator-- ();
const sc_signed oper ator-- ( i nt );
// Bit selecti on
sc_si gned_bi tref

oper ator [] ( i nt i );
sc_si gned_bi tref_r

operator [] ( i nt i ) const;
// Part selection
sc_si gned_subr ef

r ange( i nt i , i nt j );
sc_si gned_subr ef_r

r ange( i nt i , i nt j ) const;
sc_si gned_subr ef

oper ator () ( i nt i , int j );


sc_si gned_subr ef_r

oper ator () ( i nt i , int j ) const;


// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref i x ) const;
// Pri nt functions
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
// Capacity
int length() const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Overloaded operators
} ;
} // namespace sc_dt
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


230
Copyright 2012 IEEE. All rights reserved.
7.6.3.3 Constraints on usage
An obj ect of type sc_signed shall not be used as a di rect replacement f or a C++ integer type si nce no
implici t type conversi on member f unctions are provi ded. An expl icit type conversion is required to pass the
val ue of an sc_signed object as an argument to a f uncti on expecti ng a C++ integer value argument.
7.6.3.4 Constructors
expl icit sc_signed( i nt nb = sc_length_param().l en() );
Constructor sc_signed shall create an sc_signed obj ect of word l ength specif ied by nb. Thi s i s the
def aul t constructor when nb i s not speci fi ed (in whi ch case i ts val ue i s set by the current length
context). The i niti al val ue of the obj ect shal l be 0.
templ ate< cl ass T >
sc_signed( const sc_generi c_base<T>& a );
Constructor sc_signed shal l create an sc_signed object wi th a word length matching the constructor
argument. The constructor shall set the initial val ue of the object to the val ue returned from the
member f uncti on to_sc_signed of the constructor argument.
The other constructors create an sc_signed obj ect with the same word l ength and val ue as the constructor
argument.
7.6.3.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_signed, usi ng truncation or si gn-extension as descri bed i n 7.2.1.
7.6.3.6 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref ix ) const;
Member f uncti on to_str ing shall perf orm conversi on to an std::str ing representation, as described
in 7.2.11. Call ing the to_str ing f unction wi th a si ngl e argument i s equivalent to call ing the to_str ing
f uncti on with two arguments, where the second argument i s true. Call ing the to_str ing f uncti on
wi th no arguments i s equivalent to call ing the to_str ing f unction wi th two arguments, where the fi rst
argument is SC_DEC and the second argument is true.
7.6.3.7 Arithmetic, bitwise, and comparison operators
Operati ons specif ied i n Tabl e 10, Table 11, and Tabl e 12 are permitted. The foll owing appl ies:
S represents an obj ect of type sc_signed.
U represents an obj ect of type sc_unsigned.
i represents an obj ect of integer type int, long, unsigned int, unsigned long, sc_signed,
sc_unsigned, sc_int_base, or sc_uint_base.
s represents an obj ect of si gned integer type int, long, sc_signed, or sc_int_base.
The operands may al so be of any other cl ass that i s derived from those just given.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


231
Copyright 2012 IEEE. All rights reserved.
Table 10sc_signed arithmetic operations
Expr ession Retur n type Oper ation
S + i sc_si gned sc_si gned addi ti on
i + S sc_si gned sc_si gned addi ti on
U + s sc_si gned addi ti on of sc_unsi gned and si gned
s + U sc_si gned addi ti on of si gned and sc_unsi gned
S += i sc_si gned& sc_si gned assi gn sum
S - i sc_si gned sc_si gned subtracti on
i - S sc_si gned sc_si gned subtraction
U - i sc_si gned sc_unsi gned subtracti on
i - U sc_si gned sc_unsi gned subtracti on
S -= i sc_si gned& sc_si gned assi gn di f f erence
S * i sc_si gned sc_si gned mul ti pl i cati on
i * S sc_si gned sc_si gned mul ti pl i cati on
U * s sc_si gned mul ti pl i cati on of sc_unsi gned by signed
s * U sc_si gned mul ti pl i cati on of si gned by sc_unsigned
S * = i sc_si gned& sc_si gned assi gn product
S / i sc_si gned sc_si gned divi si on
i / S sc_si gned sc_si gned divi si on
U / s sc_si gned di vi si on of sc_unsi gned by si gned
s / U sc_si gned di vi si on of si gned by sc_unsi gned
S /= i sc_si gned& sc_si gned assi gn quoti ent
S % i sc_si gned sc_si gned remai nder
i % S sc_si gned sc_si gned remai nder
U % s sc_si gned remai nder of sc_unsi gned wi th si gned
s % U sc_si gned remai nder of si gned wi th sc_unsigned
S %= i sc_si gned& sc_si gned assi gn remainder
+S sc_si gned sc_si gned unary pl us
-S sc_si gned sc_si gned unary mi nus
-U sc_si gned sc_unsi gned unary mi nus
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


232
Copyright 2012 IEEE. All rights reserved.
I f the result of any arithmetic operati on i s zero, the word length of the return value shall be set by the
sc_length_context in scope. Otherwi se, the foll owing rules apply:
Addition shall return a result with a word length that is equal to the word length of the longest
operand plus one.
Multiplication shall return a result with a word length that is equal to the sum of the word lengths of
the two operands.
Remainder shall return a result with a word length that is equal to the word length of the shortest
operand.
All other arithmetic operators shall return a result with a word length that is equal to the word length
of the longest operand.
Table 11sc_signed bitwise operations
Expr ession Retur n type Oper ation
S & i sc_si gned sc_si gned bi twi se and
i & S sc_si gned sc_si gned bi twi se and
U & s sc_si gned sc_unsi gned bi twi se and si gned
s & U sc_si gned si gned bi twi se and sc_unsigned
S & = i sc_si gned& sc_si gned assi gn bi twi se and
S | i sc_si gned sc_si gned bi twi se or
i | S sc_si gned sc_si gned bi twi se or
U | s sc_si gned sc_unsi gned bi twi se or si gned
s | U sc_si gned si gned bi twi se or sc_unsigned
S |= i sc_si gned& sc_si gned assi gn bi twi se or
S ^ i sc_si gned sc_si gned bi twi se excl usi ve or
i ^ S sc_si gned sc_si gned bi twi se excl usi ve or
U ^ s sc_si gned sc_unsi gned bi twise excl usive or si gned
s ^ U sc_si gned sc_unsi gned bi twise excl usive or si gned
S ^= i sc_si gned& sc_si gned assi gn bi twi se exclusi ve or
S << i sc_si gned sc_si gned l ef t-shi f t
U << S sc_unsi gned sc_unsi gned lef t-shif t
S <<= i sc_si gned& sc_si gned assi gn l ef t-shi f t
S >> i sc_si gned sc_si gned ri ght-shi f t
U >> S sc_unsi gned sc_unsi gned ri ght-shi ft
S >>= i sc_si gned& sc_si gned assi gn ri ght-shi f t
~S sc_si gned sc_si gned bi twi se compl ement
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


233
Copyright 2012 IEEE. All rights reserved.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The left shif t operator shal l return a result wi th a word length that i s equal to the word l ength of i ts sc_signed
operand plus the right (integer) operand. Bits added on the ri ght-hand si de of the result shall be set to zero.
The ri ght shi ft operator shal l return a resul t wi th a word length that i s equal to the word length of i ts
sc_signed operand. Bi ts added on the left-hand si de of the result shall be set to the same val ue as the left-
hand bit of the sc_signed operand (a right-shif t preserves the sign).
The behavi or of a shif t operator i s undef ined if the right operand i s negative.
NOTEAn implementation is required to suppl y overl oaded operators on sc_signed obj ects to sati sfy the requi rements
of thi s subcl ause. I t i s unspeci f i ed whether these operators are members of sc_signed, global operators, or provi ded i n
some other way.
7.6.3.8 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
Table 12sc_signed comparison operations
Expr ession Retur n type Oper ation
S == i bool test equal
i == S bool test equal
S ! = i bool test not equal
i ! = S bool test not equal
S < i bool test l ess than
i < S bool test l ess than
S <= i bool test l ess than or equal
i <= S bool test l ess than or equal
S > i bool test greater than
i > S bool test greater than
S >= i bool test greater than or equal
i >= S bool test greater than or equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


234
Copyright 2012 IEEE. All rights reserved.
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.6.4 sc_unsigned
7.6.4.1 Description
Cl ass sc_unsigned represents a fi nite word-length unsi gned i nteger. The word l ength shal l be speci fi ed by a
constructor argument or, by defaul t, by the length context currentl y in scope. The word length of an
sc_unsigned obj ect is fi xed during instanti ation and shall not be subsequently changed.
The integer value shal l be stored with a fi ni te preci sion determi ned by the speci fi ed word l ength. The
precision shall not depend on the l imited resoluti on of any standard C++ integer type.
sc_unsigned is the base class f or the sc_biguint class template.
7.6.4.2 Class definition
namespace sc_dt {
class sc_unsigned
: publi c sc_val ue_base

{
f ri end cl ass sc_concatr ef

;
f ri end cl ass sc_unsi gned_bi tr ef_r

;
f ri end cl ass sc_unsi gned_bi tr ef

;
f ri end cl ass sc_unsi gned_subref_r

;
f ri end cl ass sc_unsi gned_subref

;
f riend cl ass sc_si gned;
f ri end cl ass sc_si gned_subr ef

;
publ ic:
// Constructors
expl icit sc_unsigned( i nt nb = sc_length_param().l en() );
sc_unsigned( const sc_unsigned& v );
sc_unsigned( const sc_si gned& v );
templ ate<cl ass T>
expl icit sc_unsigned( const sc_generi c_base<T>& v );
expl icit sc_unsigned( const sc_bv_base& v );
expl icit sc_unsigned( const sc_lv_base& v );
expl icit sc_unsigned( const sc_int_subref_r& v );
expl icit sc_unsigned( const sc_uint_subref_r& v );
expl icit sc_unsigned( const sc_si gned_subref _r& v );
expl icit sc_unsigned( const sc_unsigned_subref_r& v );
// Assi gnment operators
sc_unsi gned& oper ator = ( const sc_unsigned& v);
sc_unsi gned& oper ator = ( const sc_unsi gned_subref_r

& a );
templ ate<cl ass T>
sc_unsi gned& oper ator = ( const sc_generi c_base<T>& a );
sc_unsi gned& oper ator = ( const sc_si gned& v );
sc_unsi gned& oper ator = ( const sc_si gned_subr ef_r

& a );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


235
Copyright 2012 IEEE. All rights reserved.
sc_unsi gned& oper ator = ( const char* v);
sc_unsi gned& oper ator = ( i nt64 v );
sc_unsi gned& oper ator = ( ui nt64 v );
sc_unsi gned& oper ator = ( l ong v );
sc_unsi gned& oper ator = ( unsigned long v );
sc_unsigned& oper ator = ( i nt v );
sc_unsi gned& oper ator = ( unsigned int v );
sc_unsi gned& oper ator = ( double v );
sc_unsi gned& oper ator = ( const sc_int_base& v );
sc_unsi gned& oper ator = ( const sc_uint_base& v );
sc_unsi gned& oper ator = ( const sc_bv_base& );
sc_unsi gned& oper ator = ( const sc_lv_base& );
sc_unsigned& oper ator = ( const sc_fxval& );
sc_unsi gned& oper ator = ( const sc_fxval _fast& );
sc_unsi gned& oper ator = ( const sc_fxnum& );
sc_unsi gned& oper ator = ( const sc_fxnum_fast& );
// Destructor
~sc_unsigned();
// Increment operators
sc_unsi gned& oper ator ++ ();
const sc_unsigned oper ator ++ ( i nt );
// Decrement operators
sc_unsi gned& oper ator-- ();
const sc_unsigned oper ator-- ( i nt) ;
// Bit selecti on
sc_unsi gned_bi tr ef

oper ator [] ( i nt i );
sc_unsi gned_bi tr ef_r

oper ator [] ( i nt i ) const;


// Part selection
sc_unsi gned_subref

r ange ( i nt i , int j );
sc_unsi gned_subref_r

r ange( i nt i , i nt j ) const;
sc_unsi gned_subref

oper ator () ( i nt i , i nt j );
sc_unsi gned_subref_r

oper ator () ( i nt i , i nt j ) const;


// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref i x ) const;
// Pri nt functions
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


236
Copyright 2012 IEEE. All rights reserved.
// Capacity
int length() const; // Bit width
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Overloaded operators
} ;
} // namespace sc_dt
7.6.4.3 Constraints on usage
An obj ect of type sc_unsigned may not be used as a di rect repl acement f or a C++ i nteger type since no
implici t type conversi on member f unctions are provi ded. An expl icit type conversion is required to pass the
val ue of an sc_unsigned object as an argument to a f unction expecting a C++ i nteger val ue argument.
7.6.4.4 Constructors
expl icit sc_unsigned( i nt nb = sc_length_param().l en() );
Constructor sc_unsigned shal l create an sc_unsigned obj ect of word l ength specif ied by nb. This i s
the default constructor when nb i s not speci fied (in whi ch case its val ue is set by the current length
context). The i nitial val ue shal l be 0.
templ ate< cl ass T >
sc_unsigned( const sc_generi c_base<T>& a );
Constructor sc_unsigned shal l create an sc_unsigned object wi th a word l ength matchi ng the
constructor argument. The constructor shal l set the i ni ti al val ue of the object to the val ue returned
f rom the member functi on to_sc_unsigned of the constructor argument.
The other constructors create an sc_unsigned obj ect with the same word length and val ue as the
constructor argument.
7.6.4.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_unsigned, usi ng truncation or si gn-extension as descri bed in 7.2.1.
7.6.4.6 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref ix ) const;
Member function to_str ing shal l perf orm the conversion to an std::str ing, as described in 7.2.11.
Call ing the to_str ing f uncti on with a single argument is equi valent to call ing the to_str ing f uncti on
wi th two arguments, where the second argument is true. Call ing the to_str ing f unction wi th no
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


237
Copyright 2012 IEEE. All rights reserved.
arguments is equival ent to cal li ng the to_str ing f unction with two arguments, where the fi rst
argument is SC_DEC and the second argument is true.
7.6.4.7 Arithmetic, bitwise, and comparison operators
Operati ons specif ied i n Tabl e 13, Table 14, and Tabl e 15 are permitted. The foll owing appl ies:
S represents an obj ect of type sc_signed.
U represents an obj ect of type sc_unsigned.
i represents an obj ect of integer type int, long, unsigned int, unsigned long, sc_signed,
sc_unsigned, sc_int_base, or sc_uint_base.
s represents an obj ect of si gned integer type int, long, sc_signed, or sc_int_base.
u represents an object of unsigned integer type unsigned int, unsigned long, sc_unsigned, or
sc_uint_base.
The operands may al so be of any other cl ass that i s derived from those just given.
Table 13sc_unsigned arithmetic operations
Expr ession Retur n type Oper ation
U + u sc_unsi gned sc_unsi gned addi ti on
u + U sc_unsi gned sc_unsi gned addi ti on
U + s sc_si gned addi ti on of sc_unsi gned and si gned
s + U sc_si gned additi on of si gned and sc_unsigned
U += i sc_unsi gned& sc_unsi gned assi gn sum
U - i sc_si gned sc_unsi gned subtracti on
i - U sc_si gned sc_unsi gned subtracti on
U -= i sc_unsi gned& sc_unsi gned assi gn di f ference
U * u sc_unsi gned sc_unsi gned mul ti pl icati on
u * U sc_unsi gned sc_unsi gned mul ti pl icati on
U * s sc_si gned multi pl i cati on of sc_unsi gned by si gned
s * U sc_si gned multi pl i cati on of si gned by sc_unsigned
U * = i sc_unsi gned& sc_unsi gned assi gn product
U / u sc_unsi gned sc_unsi gned di vi si on
u / U sc_unsi gned sc_unsi gned di vi si on
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


238
Copyright 2012 IEEE. All rights reserved.
I f the result of any arithmetic operati on i s zero, the word length of the return value shall be set by the
sc_length_context in scope. Otherwi se, the foll owing rules apply:
Addition shall return a result with a word length that is equal to the word length of the longest
operand plus one.
Multiplication shall return a result with a word length that is equal to the sum of the word lengths of
the two operands.
Remainder shall return a result with a word length that is equal to the word length of the shortest
operand.
All other arithmetic operators shall return a result with a word length that is equal to the word length
of the longest operand.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The lef t shi ft operator shal l return a resul t with a word length that i s equal to the word l ength of its
sc_unsigned operand pl us the right (integer) operand. Bits added on the right-hand si de of the resul t shall be
set to zero.
The ri ght shi ft operator shal l return a resul t wi th a word length that i s equal to the word length of i ts
sc_unsigned operand. Bits added on the l ef t-hand si de of the resul t shal l be set to zero.
NOTEAn implementation is required to suppl y overl oaded operators on sc_unsigned obj ects to sati sf y the
requi rements of this subcl ause. It i s unspeci f i ed whether these operators are members of sc_unsigned, gl obal operators,
or provi ded i n some other way.
U / s sc_si gned di vi si on of sc_unsi gned by si gned
s / U sc_si gned di visi on of si gned by sc_unsi gned
U /= i sc_unsi gned& sc_unsi gned assi gn quoti ent
U % u sc_unsi gned sc_unsi gned remai nder
u % U sc_unsi gned sc_unsi gned remai nder
U % s sc_si gned remai nder of sc_unsi gned with si gned
s % U sc_si gned remai nder of si gned wi th sc_unsi gned
U %= i sc_unsi gned& sc_unsi gned assi gn remai nder
+U sc_unsi gned sc_unsi gned unary pl us
-U sc_si gned sc_unsi gned unary mi nus
Table 13sc_unsigned arithmetic operations (continued)
Expr ession Retur n type Oper ation
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


239
Copyright 2012 IEEE. All rights reserved.
7.6.4.8 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
Table 14sc_unsigned bitwise operations
Expr ession Retur n type Oper ation
U & u sc_unsi gned sc_unsi gned bi twi se and
u & U sc_unsi gned sc_unsi gned bi twi se and
U & s sc_si gned sc_unsi gned bi twi se and si gned
s & U sc_si gned si gned bi twise and sc_unsi gned
U & = i sc_unsi gned& sc_unsi gned assi gn bi twise and
U | u sc_unsi gned sc_unsi gned bi twi se or
u | U sc_unsi gned sc_unsi gned bi twi se or
U | s sc_si gned sc_unsi gned bi twi se or si gned
s | U sc_si gned si gned bi twi se or sc_unsi gned
U |= i sc_unsi gned& sc_unsi gned assi gn bi twi se or
U ^ u sc_unsi gned sc_unsi gned bi twi se excl usi ve or
u ^ U sc_unsi gned sc_unsi gned bi twi se excl usi ve or
U ^ s sc_si gned sc_unsi gned bi twi se excl usi ve or si gned
s ^ U sc_si gned sc_unsi gned bi twi se excl usi ve or si gned
U ^= i sc_unsi gned& sc_unsi gned assign bi twi se excl usi ve or
U << i sc_unsi gned sc_unsi gned l ef t-shi f t
S << U sc_si gned sc_si gned l eft-shi f t
U <<= i sc_unsi gned& sc_unsi gned assi gn l ef t-shi f t
U >> i sc_unsi gned sc_unsi gned ri ght-shi f t
S >> U sc_si gned sc_si gned right-shif t
U >>= i sc_unsi gned& sc_unsi gned assi gn ri ght-shi f t
~U sc_unsi gned sc_unsi gned bi twi se compl ement
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


240
Copyright 2012 IEEE. All rights reserved.
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.6.5 sc_bigint
7.6.5.1 Description
Class templ ate sc_bigint represents a f inite word-length si gned integer. The word l ength shall be specif ied
by a template argument. The i nteger value shall be stored wi th a fi ni te preci si on determined by the speci fi ed
word l ength. The precision shall not depend on the limited resoluti on of any standard C++ integer type.
Any publi c member f unctions of the base class sc_signed that are overri dden in class sc_bigint shall have
the same behavior i n the two cl asses. Any publi c member functions of the base cl ass not overri dden i n thi s
way shal l be publ icly inherited by cl ass sc_bigint. The operati ons speci fi ed in 7.6.3.7 are permitted f or
objects of type sc_bigint.
7.6.5.2 Class definition
namespace sc_dt {
templ ate< i nt W >
Table 15sc_unsigned comparison operations
Expr ession Retur n type Oper ation
U == i bool test equal
i == U bool test equal
U ! = i bool test not equal
i ! = U bool test not equal
U < i bool test l ess than
i < U bool test l ess than
U <= i bool test l ess than or equal
i <= U bool test l ess than or equal
U > i bool test greater than
i > U bool test greater than
U >= i bool test greater than or equal
i >= U bool test greater than or equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


241
Copyright 2012 IEEE. All rights reserved.
class sc_bigint
: publi c sc_signed
{
publ ic:
// Constructors
sc_bigint();
sc_bigint( const sc_bigint<W>& v );
sc_bigint( const sc_si gned& v );
sc_bigint( const sc_si gned_subr ef

& v );
templ ate< cl ass T >
sc_bigint( const sc_generi c_base<T>& a );
sc_bigint( const sc_unsigned& v );
sc_bigint( const sc_unsi gned_subref

& v );
sc_bigint( const char* v );
sc_bigint( i nt64 v );
sc_bigint( ui nt64 v );
sc_bigint( l ong v );
sc_bigint( unsigned long v );
sc_bigint( i nt v );
sc_bigint( unsigned int v );
sc_bigint( double v );
sc_bigint( const sc_bv_base& v );
sc_bigint( const sc_lv_base& v );
expl icit sc_bigint( const sc_fxval & v );
expl icit sc_bigint( const sc_fxval _fast& v );
expl icit sc_bigint( const sc_fxnum& v );
expl icit sc_bigint( const sc_fxnum_fast& v );
// Destructor
~sc_bigint();
// Assi gnment operators
sc_bigi nt<W>& oper ator = ( const sc_bi gint<W>& v );
sc_bigi nt<W>& oper ator = ( const sc_si gned& v );
sc_bigi nt<W>& oper ator = (const sc_si gned_subr ef

& v );
templ ate< cl ass T >
sc_bigi nt<W>& oper ator = ( const sc_generi c_base<T>& a );
sc_bigi nt<W>& oper ator = ( const sc_unsigned& v );
sc_bigi nt<W>& oper ator = ( const sc_unsi gned_subref

& v );
sc_bigi nt<W>& oper ator = ( const char* v );
sc_bigi nt<W>& oper ator = ( i nt64 v );
sc_bigi nt<W>& oper ator = ( ui nt64 v );
sc_bigi nt<W>& oper ator = ( l ong v );
sc_bigi nt<W>& oper ator = ( unsigned long v );
sc_bigi nt<W>& oper ator = ( i nt v );
sc_bigi nt<W>& oper ator = ( unsigned int v );
sc_bigi nt<W>& oper ator = ( double v );
sc_bigi nt<W>& oper ator = ( const sc_bv_base& v );
sc_bigi nt<W>& oper ator = ( const sc_lv_base& v );
sc_bigi nt<W>& oper ator = ( const sc_int_base& v );
sc_bigi nt<W>& oper ator = ( const sc_ui nt_base& v );
sc_bigi nt<W>& oper ator = ( const sc_fxval & v );
sc_bigi nt<W>& oper ator = ( const sc_fxval_fast& v );
sc_bigi nt<W>& oper ator = ( const sc_fxnum& v );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


242
Copyright 2012 IEEE. All rights reserved.
sc_bigi nt<W>& oper ator = ( const sc_fxnum_fast& v );
} ;
} // namespace sc_dt
7.6.5.3 Constraints on usage
An obj ect of type sc_bigint may not be used as a di rect replacement f or a C++ i nteger type si nce no i mpli ci t
type conversion member functions are provi ded. An expli ci t type conversion is required to pass the val ue of
an sc_bigint object as an argument to a f unction expecting a C++ i nteger val ue argument.
7.6.5.4 Constructors
sc_bigint();
Default constructor sc_bigint shall create an sc_bigint object of word l ength speci fi ed by the
templ ate argument W and shal l set the i niti al value to 0.
templ ate< cl ass T >
sc_bigint( const sc_generi c_base<T>& a );
Constructor sc_bigint shal l create an sc_bigint object of word length speci fi ed by the template
argument. The constructor shall set the initial val ue of the object to the val ue returned from the
member f uncti on to_sc_signed of the constructor argument.
Other constructors shal l create an sc_bigint obj ect of word length specif ied by the template argument W and
val ue corresponding to the integer magni tude of the constructor argument. If the word length of the specif ied
ini ti al val ue di ff ers from the template argument, truncation or sign-extension shall be used as described in
7.2.1.
NOTEMost constructors can be used as impli ci t conversi ons f rom f undamental types or SystemC data types to
sc_bigint. Hence, a f uncti on havi ng an sc_bigint parameter can be passed a f l oating-poi nt argument, f or example, and
the argument wi l l be i mpl ici tl y converted. The excepti ons are the conversions f rom f i xed-poi nt types to sc_bigint, whi ch
must be cal l ed expl i ci tl y.
7.6.5.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_bigint, usi ng truncation or si gn-extension as descri bed i n 7.2.1.
7.6.6 sc_biguint
7.6.6.1 Description
Class template sc_biguint represents a fi nite word-l ength unsigned integer. The word l ength shall be
specif ied by a template argument. The integer val ue shal l be stored wi th a f ini te preci si on determined by the
specif ied word l ength. The precision shall not depend on the l imi ted resoluti on of any standard C++ i nteger
type.
Any publi c member functions of the base cl ass sc_unsigned that are overri dden i n class sc_biguint shall
have the same behavior in the two cl asses. Any publ ic member f unctions of the base cl ass not overri dden in
thi s way shal l be publ icly inherited by class sc_biguint. The operations specif ied i n 7.6.4.7 are permi tted for
objects of type sc_biguint.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


243
Copyright 2012 IEEE. All rights reserved.
7.6.6.2 Class definition
namespace sc_dt {
templ ate< i nt W >
class sc_biguint
: publi c sc_unsigned
{
publ ic:
// Constructors
sc_biguint();
sc_biguint( const sc_biguint<W>& v );
sc_biguint( const sc_unsigned& v );
sc_biguint( const sc_unsi gned_subref

& v );
templ ate< cl ass T >
sc_biguint( const sc_generi c_base<T>& a );
sc_biguint( const sc_si gned& v );
sc_biguint( const sc_si gned_subr ef

& v );
sc_biguint( const char* v );
sc_biguint( i nt64 v );
sc_biguint( ui nt64 v );
sc_biguint( l ong v );
sc_biguint( unsigned l ong v );
sc_biguint( i nt v );
sc_biguint( unsigned int v );
sc_biguint( double v );
sc_biguint( const sc_bv_base& v );
sc_biguint( const sc_lv_base& v );
expl icit sc_biguint( const sc_fxval& v );
expl icit sc_biguint( const sc_fxval_fast& v );
expl icit sc_biguint( const sc_fxnum& v );
expl icit sc_biguint( const sc_fxnum_fast& v );
// Destructor
~sc_biguint();
// Assi gnment operators
sc_biguint<W>& oper ator = ( const sc_bi gui nt<W>& v );
sc_biguint<W>& oper ator = ( const sc_unsigned& v );
sc_biguint<W>& oper ator = ( const sc_unsi gned_subref

& v );
templ ate< cl ass T >
sc_biguint<W>& oper ator = ( const sc_generi c_base<T>& a );
sc_biguint<W>& oper ator = ( const sc_si gned& v );
sc_biguint<W>& oper ator = ( const sc_si gned_subr ef

& v );
sc_biguint<W>& oper ator = ( const char* v );
sc_biguint<W>& oper ator = ( i nt64 v );
sc_biguint<W>& oper ator = ( ui nt64 v );
sc_biguint<W>& oper ator = ( l ong v );
sc_biguint<W>& oper ator = ( unsigned long v );
sc_biguint<W>& oper ator = ( i nt v );
sc_biguint<W>& oper ator = ( unsigned int v );
sc_biguint<W>& oper ator = ( double v );
sc_biguint<W>& oper ator = ( const sc_bv_base& v );
sc_biguint<W>& oper ator = ( const sc_lv_base& v );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


244
Copyright 2012 IEEE. All rights reserved.
sc_biguint<W>& oper ator = ( const sc_int_base& v );
sc_biguint<W>& oper ator = ( const sc_ui nt_base& v );
sc_biguint<W>& oper ator = ( const sc_fxval & v );
sc_biguint<W>& oper ator = ( const sc_fxval _fast& v );
sc_biguint<W>& oper ator = ( const sc_fxnum& v );
sc_biguint<W>& oper ator = ( const sc_fxnum_fast& v );
} ;
} // namespace sc_dt
7.6.6.3 Constraints on usage
An obj ect of type sc_biguint may not be used as a direct repl acement for a C++ i nteger type si nce no
implici t type conversi on member f unctions are provi ded. An expl icit type conversion is required to pass the
val ue of an sc_biguint obj ect as an argument to a functi on expecti ng a C++ integer value argument.
7.6.6.4 Constructors
sc_biguint();
Default constructor sc_biguint shal l create an sc_biguint object of word length specif ied by the
templ ate argument W and shal l set the i niti al value to 0.
templ ate< cl ass T >
sc_biguint( const sc_generi c_base<T>& a );
Constructor shall create an sc_biguint obj ect of word length specifi ed by the template argument.
The constructor shal l set the ini ti al value of the object to the val ue returned f rom the member
f uncti on to_sc_unsigned of the constructor argument.
The other constructors shal l create an sc_biguint obj ect of word length specif i ed by the template argument
W and value correspondi ng to the i nteger magnitude of the constructor argument. I f the word l ength of the
specif ied i nitial value di ff ers from the template argument, truncati on or si gn-extension shall be used as
descri bed in 7.2.1.
NOTEMost constructors can be used as impli ci t conversi ons f rom f undamental types or SystemC data types to
sc_biguint. Hence, a f uncti on havi ng an sc_biguint parameter can be passed a f l oati ng-poi nt argument, f or exampl e,
and the argument wi ll be i mpl i ci tl y converted. The excepti ons are the conversi ons f rom fi xed-poi nt types to sc_biguint,
whi ch must be cal l ed expl i ci tly.
7.6.6.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_biguint, usi ng truncati on or si gn-extension, as descri bed in 7.2.1.
7.6.7 Bit-selects
7.6.7.1 Description
Cl ass sc_si gned_bi tref_r

represents a bit selected from an sc_signed used as an rval ue.


Class sc_si gned_bi tref

represents a bit selected f rom an sc_signed used as an l val ue.


Cl ass sc_unsi gned_bi tr ef_r

represents a bit selected f rom an sc_unsigned used as an rval ue.


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


245
Copyright 2012 IEEE. All rights reserved.
Cl ass sc_unsi gned_bi tr ef

represents a bit sel ected f rom an sc_unsigned used as an l val ue.


7.6.7.2 Class definition
namespace sc_dt {
class sc_si gned_bi tref_r

: publi c sc_val ue_base

{
f riend cl ass sc_si gned;
f ri end cl ass sc_si gned_bi tref

;
publ ic:
// Copy constructor
sc_si gned_bi tref_r

( const sc_si gned_bi tref_r

& a );
// Destructor
virtual ~sc_si gned_bi tref_r

();
// Capacity
int length() const;
// Impl icit conversi on to ui nt64
oper ator uint64 () const;
bool oper ator ! () const;
bool oper ator ~ () const;
// Expl icit conversions
bool to_bool() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_si gned_bi tref_r

();
pri vate:
// Di sabl ed
sc_si gned_bi tref_r

& oper ator = ( const sc_si gned_bi tref_r

& );
} ;
// -----------------------------------------------------------------
class sc_si gned_bi tref

: publi c sc_si gned_bi tref_r

{
f riend cl ass sc_si gned;
publ ic:
// Copy constructor
sc_si gned_bi tref

( const sc_si gned_bi tref

& a );
// Assi gnment operators
sc_si gned_bi tref

& oper ator = ( const sc_si gned_bi tref_r

& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


246
Copyright 2012 IEEE. All rights reserved.
sc_si gned_bi tref

& oper ator = ( const sc_si gned_bi tref

& );
sc_si gned_bi tref

& oper ator = ( bool );


sc_si gned_bi tref

& oper ator & = ( bool );


sc_si gned_bi tref

& oper ator |= ( bool );


sc_si gned_bi tref

& oper ator ^= ( bool );


// Other methods
void scan( std::i stream& i s = std::ci n );
protected:
sc_si gned_bi tref

();
} ;
// -----------------------------------------------------------------
class sc_unsi gned_bi tr ef_r


: publi c sc_val ue_base

{
f riend cl ass sc_unsigned;
publ ic:
// Copy constructor
sc_unsi gned_bi tr ef_r

( const sc_unsi gned_bi tr ef_r

& a );
// Destructor
virtual ~sc_unsi gned_bi tr ef_r

();
// Capacity
int length() const;
// Impl icit conversi on to ui nt64
oper ator uint64 () const;
bool oper ator ! () const;
bool oper ator ~ () const;
// Expl icit conversions
bool to_bool() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_unsi gned_bi tr ef_r

();
pri vate:
// Di sabl ed
sc_unsi gned_bi tr ef_r

& oper ator = ( const sc_unsi gned_bi tr ef_r

& );
} ;
// -----------------------------------------------------------------
class sc_unsi gned_bi tr ef

: publi c sc_unsi gned_bi tr ef_r

IEEE Std 1666-2011


IEEE Standard for Standard SystemC

Language Reference Manual


247
Copyright 2012 IEEE. All rights reserved.
{
f riend cl ass sc_unsigned;
publ ic:
// Copy constructor
sc_unsi gned_bi tr ef

( const sc_unsi gned_bi tr ef

& a );
// Assi gnment operators
sc_unsi gned_bi tr ef

& oper ator = ( const sc_unsi gned_bi tr ef_r

& );
sc_unsi gned_bi tr ef

& oper ator = ( const sc_unsi gned_bi tr ef

& );
sc_unsi gned_bi tr ef

& oper ator = ( bool );


sc_unsi gned_bi tr ef

& oper ator & = ( bool );


sc_unsi gned_bi tr ef

& oper ator |= ( bool );


sc_unsi gned_bi tr ef

& oper ator ^= ( bool );


// Other methods
void scan( std::i stream& i s = std::ci n );
protected:
sc_unsi gned_bi tr ef

();
} ;
} // namespace sc_dt
7.6.7.3 Constraints on usage
Bit-select objects shal l only be created usi ng the bi t-sel ect operators of an sc_signed or sc_unsigned object
(or an i nstance of a class deri ved from sc_signed or sc_unsigned).
An appl ication shall not expli citl y create an i nstance of any bi t-sel ect class.
An appl ication should not decl are a reference or pointer to any bit-sel ect obj ect.
I t is strongly recommended that an appl ication avoi d the use of a bi t-sel ect as the return type of a f unction
because the l if etime of the obj ect to whi ch the bi t-select ref ers may not extend beyond the f uncti on return
statement.
Exampl e:
sc_dt::sc_signed_bi tref get_bit_n(sc_si gned iv, int n) {
return iv[n] ; // Unsafe: returned bi t-sel ect ref erences local vari abl e
}
7.6.7.4 Assignment operators
Overl oaded assi gnment operators f or the lvalue bi t-sel ects shall provide conversi on from bool val ues.
Assi gnment operators f or rvalue bi t-sel ects shall be declared as pri vate to prevent their use by an
appl ication.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


248
Copyright 2012 IEEE. All rights reserved.
7.6.7.5 Implicit type conversion
oper ator uint64 () const;
oper ator uint64 can be used for i mpli ci t type conversi on f rom a bi t-sel ect to a native C++ unsi gned
integer having exactly 64 bits. If the selected bit has the val ue ' 1' (true), the conversi on shall return
the val ue 1; otherwise, i t shal l return 0.
bool oper ator ! () const;
bool oper ator ~ () const;
oper ator ! and oper ator ~ shall return a C++ bool val ue that is the inverse of the sel ected bi t.
7.6.7.6 Other member functions
void scan( std::i stream& i s = std::ci n );
Member f unction scan shal l set the value of the bit referenced by an lvalue bit-sel ect. The val ue
shal l correspond to the C++ bool val ue obtai ned by reading the next formatted character string from
the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member function pr int shal l print the value of the bi t referenced by the bi t-select to the speci fi ed
output stream (see 7.2.10). The formatti ng shal l be i mplementati on-defi ned but shall be equi val ent
to pri nti ng the val ue returned by member functi on to_bool.
int length() const;
Member f uncti on length shall unconditi onal ly return a word l ength of 1 (see 7.2.4).
7.6.8 Part-selects
7.6.8.1 Description
Cl ass sc_si gned_subr ef_r

represents a signed integer part-select from an sc_signed used as an rval ue.


Cl ass sc_si gned_subr ef

represents a si gned integer part-sel ect f rom an sc_signed used as an l val ue.
Cl ass sc_unsi gned_subref_r

represents an unsigned integer part-select from an sc_unsigned used as an


rvalue.
Cl ass sc_unsi gned_subref

represents an unsi gned integer part-select from an sc_unsigned used as an


lvalue.
7.6.8.2 Class definition
namespace sc_dt {
class sc_si gned_subr ef_r


: publ ic sc_val ue_base

{
f riend cl ass sc_si gned;
f riend cl ass sc_unsigned;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


249
Copyright 2012 IEEE. All rights reserved.
publ ic:
// Copy constructor
sc_si gned_subr ef_r

( const sc_si gned_subr ef_r

& a );
// Destructor
virtual ~sc_unsi gned_subref_r

();
// Capacity
int length() const;
// Impl icit conversion to sc_unsigned
oper ator sc_unsigned () const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep, bool w_pref i x ) const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_si gned_subr ef_r

();
pri vate:
// Di sabl ed
sc_si gned_subr ef_r

& oper ator = ( const sc_si gned_subr ef_r

& );
} ;
// --------------------------------------------------------------
class sc_si gned_subr ef

: publi c sc_si gned_subr ef_r

{
f riend cl ass sc_si gned;
publ ic:
// Copy constructor
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


250
Copyright 2012 IEEE. All rights reserved.
sc_si gned_subr ef

( const sc_si gned_subr ef

& a );
// Assi gnment operators
sc_si gned_subr ef

& oper ator = ( const sc_si gned_subr ef_r

& a );
sc_si gned_subr ef

& oper ator = ( const sc_si gned_subr ef

& a );
sc_si gned_subr ef

& oper ator = ( const sc_si gned& a );


templ ate< cl ass T >
sc_si gned_subr ef

& oper ator = ( const sc_generi c_base<T>& a );


sc_si gned_subr ef

& oper ator = ( const sc_unsi gned_subref_r

& a );
sc_si gned_subr ef

& oper ator = ( const sc_unsigned& a );


sc_si gned_subr ef

& oper ator = ( const char* a );


sc_si gned_subr ef

& oper ator = ( unsigned l ong a );


sc_si gned_subr ef

& oper ator = ( l ong a );


sc_si gned_subr ef

& oper ator = ( unsigned i nt a );


sc_si gned_subr ef

& oper ator = ( i nt a );


sc_si gned_subr ef

& oper ator = ( ui nt64 a );


sc_si gned_subr ef

& oper ator = ( i nt64 a );


sc_si gned_subr ef

& oper ator = ( double a );


sc_si gned_subr ef

& oper ator = ( const sc_int_base& a );


sc_si gned_subr ef

& oper ator = ( const sc_uint_base& a );


// Other methods
void scan( std::i stream& i s = std::ci n );
pri vate:
// Di sabl ed
sc_si gned_subr ef

();
} ;
// --------------------------------------------------------------
class sc_unsi gned_subref_r

: publi c sc_val ue_base

{
f riend cl ass sc_si gned;
f riend cl ass sc_unsigned;
publ ic:
// Copy constructor
sc_unsi gned_subref_r

( const sc_unsi gned_subref_r

& a );
// Destructor
virtual ~sc_unsi gned_subref_r

();
// Capacity
int length() const;
// Impl icit conversion to sc_unsigned
oper ator sc_unsigned () const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


251
Copyright 2012 IEEE. All rights reserved.
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
protected:
sc_unsi gned_subref_r

();
pri vate:
// Di sabl ed
sc_unsi gned_subref _r& oper ator = ( const sc_unsi gned_subref_r

& );
} ;
// --------------------------------------------------------------
class sc_unsi gned_subref

: publi c sc_unsi gned_subref_r

{
f riend cl ass sc_unsigned;
publ ic:
// Copy constructor
sc_unsi gned_subref

( const sc_unsi gned_subref

& a );
// Assi gnment operators
sc_unsi gned_subref

& oper ator = ( const sc_unsi gned_subref_r

& a );
sc_unsi gned_subref

& oper ator = ( const sc_unsi gned_subref

& a );
sc_unsi gned_subref

& oper ator = ( const sc_unsigned& a );


templ ate<cl ass T>
sc_unsi gned_subref

& oper ator = ( const sc_generi c_base<T>& a );


sc_unsi gned_subref

& oper ator = ( const sc_si gned_subref_r& a );


sc_unsi gned_subref

& oper ator = ( const sc_si gned& a );


sc_unsi gned_subref

& oper ator = ( const char* a );


sc_unsi gned_subref

& oper ator = ( unsi gned long a );


sc_unsi gned_subref

& oper ator = ( l ong a );


sc_unsi gned_subref

& oper ator = ( unsi gned int a );


sc_unsi gned_subref

& oper ator = ( i nt a );


sc_unsi gned_subref

& oper ator = ( uint64 a );


sc_unsi gned_subref

& oper ator = ( i nt64 a );


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


252
Copyright 2012 IEEE. All rights reserved.
sc_unsi gned_subref

& oper ator = ( double a );


sc_unsi gned_subref

& oper ator = ( const sc_int_base& a );


sc_unsi gned_subref

& oper ator = ( const sc_ui nt_base& a );


// Other methods
void scan( std::i stream& i s = std::ci n );
protected:
sc_unsi gned_subref

();
} ;
} // namespace sc_dt
7.6.8.3 Constraints on usage
I nteger part-select objects shal l only be created using the part-select operators of an sc_signed or
sc_unsigned obj ect (or an i nstance of a class derived f rom sc_signed or sc_unsigned), as descri bed i n 7.2.6.
An appl ication shall not expli citl y create an instance of any integer part-sel ect cl ass.
An appl ication should not declare a reference or pointer to any i nteger part-select object.
I t i s strongly recommended that an appli cation avoi d the use of a part-select as the return type of a functi on
because the li feti me of the obj ect to which the part-select refers may not extend beyond the functi on return
statement.
Exampl e:
sc_dt::sc_signed_subref get_byte(sc_signed s, int pos) {
return s(pos+7,pos); // Unsafe: returned part-select ref erences l ocal vari abl e
}
NOTEThe left-hand index of a finite-precisi on i nteger part-sel ect may be l ess than the ri ght-hand i ndex. The bi t order
i n the part-sel ect i s then the reverse of that i n the ori gi nal i nteger.
7.6.8.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to lval ue integer part-sel ects. I f the size of a data type or stri ng li teral operand dif fers
f rom the i nteger part-sel ect word l ength, truncation, zero-extensi on, or sign-extensi on shall be used, as
descri bed in 7.2.1.
Assi gnment operators for rvalue integer part-selects shal l be decl ared as pri vate to prevent their use by an
appl ication.
7.6.8.5 Implicit type conversion
sc_si gned_subr ef_r

:: oper ator sc_unsigned () const;


sc_unsi gned_subr ef_r

:: oper ator sc_unsigned () const;


oper ator sc_unsigned can be used f or impl icit type conversi on f rom integer part-sel ects to
sc_unsigned.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


253
Copyright 2012 IEEE. All rights reserved.
NOTEThese operators are used by the output stream operator and by member f uncti ons of other data type
cl asses that are not expl i ci tl y overl oaded f or f i ni te-preci sion i nteger part-sel ects.
7.6.8.6 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
Member functi on to_str ing shall perf orm a conversi on to an std::str ing representati on, as descri bed
in 7.2.11. Call ing the to_str ing f unction wi th a si ngl e argument i s equivalent to call ing the to_str ing
f uncti on with two arguments, where the second argument i s true. Call ing the to_str ing f uncti on
wi th no arguments i s equi val ent to call ing the to_str ing functi on with two arguments where the f irst
argument is SC_DEC and the second argument is true.
7.6.8.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member function scan shal l set the values of the bi ts ref erenced by an lvalue part-select by reading
the next formatted character string from the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member functi on pr int shall print the val ues of the bi ts referenced by the part-sel ect to the specif ied
output stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length of the part-select (see 7.2.4).
7.7 Integer concatenations
7.7.1 Description
Cl ass sc_concatr ef

represents a concatenation of bits f rom one or more objects whose concatenati on base
types are SystemC integers.
7.7.2 Class definition
namespace sc_dt {
class sc_concatr ef


: publi c sc_generic_base<sc_concatr ef

>, publ ic sc_val ue_base

{
publ ic:
// Destructor
virtual ~sc_concatr ef

();
// Capacity
unsi gned int length() const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


254
Copyright 2012 IEEE. All rights reserved.
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
doubl e to_double() const;
void to_sc_signed( sc_si gned& target ) const;
void to_sc_unsigned( sc_unsigned& target ) const;
// Impl icit conversions
oper ator uint64() const;
oper ator const sc_unsigned& () const;
// Unary operators
sc_unsi gned oper ator + () const;
sc_unsi gned oper ator- () const;
sc_unsi gned oper ator ~ () const;
// Expl icit conversion to character stri ng
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
// Assi gnment operators
const sc_concatr ef

& oper ator = ( i nt v );


const sc_concatr ef

& oper ator = ( unsigned int v );


const sc_concatr ef

& oper ator = ( l ong v );


const sc_concatr ef

& oper ator = ( unsi gned long v );


const sc_concatr ef

& oper ator = ( i nt64 v );


const sc_concatr ef

& oper ator = ( ui nt64 v );


const sc_concatr ef

& oper ator = ( const sc_concatr ef

& v );
const sc_concatr ef

& oper ator = ( const sc_si gned& v );


const sc_concatr ef

& oper ator = ( const sc_unsigned& v );


const sc_concatr ef

& oper ator = ( const char* v_p );


const sc_concatr ef

& oper ator = ( const sc_bv_base& v );


const sc_concatr ef

& oper ator = ( const sc_lv_base& v );


// Reduce methods
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& is );
pri vate:
sc_concatr ef

( const sc_concatr ef

& );
~sc_concatr ef

();
} ;
sc_concatr ef

& concat( sc_val ue_base

& a , sc_val ue_base

& b );
const sc_concatr ef

& concat( const sc_val ue_base

& a , const sc_val ue_base

& b );
const sc_concatr ef

& concat( const sc_val ue_base

& a, bool b );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


255
Copyright 2012 IEEE. All rights reserved.
const sc_concatr ef

& concat( bool a , const sc_val ue_base

& b );
sc_concatr ef

& oper ator, ( sc_val ue_base

& a , sc_val ue_base

& b );
const sc_concatr ef

& oper ator, ( const sc_val ue_base

& a , const sc_val ue_base

& b );
const sc_concatr ef

& oper ator, ( const sc_val ue_base

& a , bool b );
const sc_concatr ef

& oper ator, ( bool a , const sc_val ue_base

& b );
} // namespace sc_dt
7.7.3 Constraints on usage
I nteger concatenati on objects shall only be created using the concat functi on (or oper ator,) accordi ng to the
rul es in 7.2.7.
At least one of the concatenation arguments shall be an object wi th a SystemC integer concatenati on base
type, that is, an i nstance of a class derived directly or i ndi rectly f rom class sc_val ue_base

.
A si ngl e concatenation argument (that is, one of the two arguments to the concat function or oper ator,) may
be a bool value, a reference to a sc_core::sc_signal<bool,WRI TER_POLI CY> channel, or a reference to a
sc_core::sc_in<bool>, sc_core::sc_inout<bool>, or sc_core::sc_out<bool> port.
An appli cation shall not expl icitly create an i nstance of any i nteger concatenation class. An appl ication shall
not impl icitly create an instance of any integer concatenation cl ass by using it as a f uncti on argument or as a
f uncti on return val ue.
An appl ication should not declare a ref erence or poi nter to any i nteger concatenation object.
7.7.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to lvalue integer concatenati ons. If the size of a data type or string li teral operand
dif fers f rom the integer concatenation word l ength, truncation, zero-extension, or sign-extension shall be
used, as descri bed in 7.2.1.
Assi gnment operators f or rval ue integer concatenations shall not be cal led by an appl icati on.
7.7.5 Implicit type conversion
oper ator uint64 () const;
oper ator const sc_unsigned& () const;
Operators uint64 and sc_unsigned shal l provide impl ici t unsigned type conversion f rom an i nteger
concatenation to a nati ve C++ unsigned i nteger having exactly 64 bits or a an sc_unsigned obj ect
wi th a length equal to the total number of bi ts contained wi thin the obj ects referenced by the
concatenation.
NOTEEnables the use of standard C++ and SystemC bitwi se logi cal and ari thmeti c operators wi th i nteger
concatenati on obj ects.
7.7.6 Explicit type conversion
const std::string to_str ing( sc_numrep numrep = SC_DEC ) const;
const std::string to_str ing( sc_numrep numrep , bool w_pref ix ) const;
Member f unction to_str ing shal l convert the object to an std::str ing representation, as described in
7.2.11. Cal li ng the to_str ing function with a single argument is equivalent to call ing the to_str ing
f uncti on with two arguments, where the second argument i s true. Call ing the to_str ing f unction wi th
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


256
Copyright 2012 IEEE. All rights reserved.
no arguments is equi val ent to call ing the to_str ing f unction wi th two arguments, where the f i rst
argument is SC_DEC and the second argument is true.
7.7.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member f uncti on scan shall set the val ues of the bits ref erenced by an lvalue concatenati on by
reading the next f ormatted character stri ng f rom the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l pri nt the val ues of the bits ref erenced by the concatenation to the
specif ied output stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length of the concatenation (see 7.2.4).
7.8 Generic base proxy class
7.8.1 Description
Class templ ate sc_gener ic_base provides a common proxy base cl ass f or appli cation-defi ned data types that
are required to be converted to a SystemC i nteger.
7.8.2 Class definition
namespace sc_dt {
templ ate< cl ass T >
class sc_gener ic_base
{
publ ic:
inl ine const T* oper ator-> () const;
inl ine T* oper ator-> ();
} ;
} // namespace sc_dt
7.8.3 Constraints on usage
An appl ication shall not explici tly create an i nstance of sc_gener ic_base.
Any appli cation-defi ned type deri ved f rom sc_gener ic_base shall provide the f oll owing publi c const
member functi ons:
int length() const;
Member f uncti on length shall return the number of bi ts requi red to hol d the i nteger val ue.
uint64 to_uint64() const;
Member functi on to_uint64 shall return the val ue as a native C++ unsigned i nteger having exactly
64 bi ts.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


257
Copyright 2012 IEEE. All rights reserved.
int64 to_int64() const;
Member f unction to_int64 shal l return the val ue as a nati ve C++ signed i nteger having exactl y 64
bits.
void to_sc_unsigned( sc_unsigned& ) const;
Member function to_sc_unsigned shal l return the value as an unsigned i nteger using the
sc_unsi gned argument passed by ref erence.
void to_sc_signed( sc_si gned& ) const;
Member function to_sc_signed shall return the value as a signed integer using the sc_si gned
argument passed by reference.
7.9 Logic and vector types
7.9.1 Type definitions
The fol lowi ng enumerated type defini ti on is used by the l ogi c and vector type classes. Its li teral values
represent (i n numerical order) the four possi bl e l ogic states: l ogi c 0, l ogi c 1, hi gh-i mpedance, and unknown,
respecti vel y. This type i s not intended to be used di rectly by an appli cati on, which should instead use the
character li teral s ' 0' , ' 1' , ' Z' , and ' X ' to represent the logic states, or the appl icati on may use the constants
SC_LOGI C_0, SC_LOGIC_1, SC_LOGI C_Z, and SC_LOGI C_X i n contexts where the character l iterals
would be ambiguous.
namespace sc_dt {
enum sc_logic_value_t
{
Log_0 = 0,
Log_1,
Log_Z,
Log_X
} ;
} // namespace sc_dt
7.9.2 sc_logic
7.9.2.1 Description
Cl ass sc_logic represents a single bit with a value corresponding to any one of the four l ogi c states.
Appli cations should use the character li teral s '0' , '1' , 'Z ', and ' X' to represent the states logi c 0, logi c 1, high-
impedance, and unknown, respecti vel y. The lowercase character li teral s ' z' and ' x' are acceptable
alternatives to ' Z' and 'X ' , respectively. Any other character used as an sc_logic li teral shall be i nterpreted as
the unknown state.
The C++ bool val ues false and true may be used as arguments to sc_logic constructors and operators. They
shal l be i nterpreted as l ogi c 0 and l ogi c 1, respectivel y.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


258
Copyright 2012 IEEE. All rights reserved.
Logi c operations shal l be permi tted f or sc_logic values f ol lowi ng the truth tables shown in Tabl e 16,
Tabl e 17, Tabl e 18, and Tabl e 19.
Table 16sc_logic AND truth table
' 0' ' 1' ' Z' ' X'
' 0' '0' '0' '0' '0'
' 1' '0' '1' ' X' 'X'
' Z' '0' 'X' 'X' 'X'
' X' '0' 'X' 'X' 'X'
Table 17sc_logic OR truth table
' 0' ' 1' ' Z' ' X'
' 0' '0' '1' ' X' 'X'
' 1' '1' '1' '1' '1'
' Z' 'X' '1' 'X' 'X'
' X' 'X' '1' 'X' 'X'
Table 18sc_logic exclusive or truth table
' 0' ' 1' ' Z' ' X'
' 0' '0' '1' ' X' 'X'
' 1' '1' '0' ' X' 'X'
' Z' 'X' 'X' 'X' 'X'
' X' 'X' 'X' 'X' 'X'
Table 19sc_logic complement truth table
' 0' ' 1' ' Z' ' X'
'1' '0' ' X' 'X'
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


259
Copyright 2012 IEEE. All rights reserved.
7.9.2.2 Class definition
namespace sc_dt {
class sc_logic
{
publ ic:
// Constructors
sc_logic();
sc_logic( const sc_logic& a );
sc_logic( sc_l ogi c_value_t v );
expl icit sc_logic( bool a );
expl icit sc_logic( char a );
expl icit sc_logic( i nt a );
// Destructor
~sc_logic();
// Assi gnment operators
sc_logi c& oper ator = ( const sc_logic& a );
sc_logi c& oper ator = ( sc_l ogic_value_t v );
sc_l ogi c& oper ator = ( bool a );
sc_logi c& oper ator = ( char a );
sc_logi c& oper ator = ( i nt a );
// Expl icit conversions
sc_logi c_value_t value() const;
char to_char() const;
bool to_bool() const;
bool is_01() const;
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
pri vate:
// Di sabl ed
expl icit sc_logic( const char* );
sc_logi c& oper ator = ( const char* );
} ;
} // namespace sc_dt
7.9.2.3 Constraints on usage
An integer argument to an sc_logic constructor or operator shall be equi val ent to the correspondi ng
sc_logic_value_t enumerated value. I t shall be an error if any such integer argument i s outside the range 0 to
3.
A literal val ue assi gned to an sc_logicobject or used to i nitiali ze an sc_logicobj ect may be a character l iteral
but not a string li teral .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


260
Copyright 2012 IEEE. All rights reserved.
7.9.2.4 Constructors
sc_logic();
Default constructor sc_logic shall create an sc_logic obj ect with a val ue of unknown.
sc_logic( const sc_logic& a );
sc_logic( sc_l ogi c_value_t v );
expl icit sc_logic( bool a );
expl icit sc_logic( char a );
expl icit sc_logic( i nt a );
Constructor sc_logic shall create an sc_logic obj ect with the value speci fi ed by the argument.
7.9.2.5 Explicit type conversion
sc_logi c_value_t value() const;
Member f uncti on value shall convert the sc_logic val ue to the sc_logic_value_t equi val ent.
char to_char() const;
Member f uncti on to_char shall convert the sc_logic val ue to the char equi val ent.
bool to_bool() const;
Member f uncti on to_bool shall convert the sc_logic val ue to false or true. It shall be an error to call
thi s f unction i f the sc_logic val ue i s not l ogi c 0 or l ogi c 1.
bool is_01() const;
Member functi on is_01 shall return true i f the sc_logic value i s logic 0 or logic 1; otherwi se, the
return val ue shal l be false.
7.9.2.6 Bitwise and comparison operators
The operati ons speci fi ed i n Table 20 shall be permitted. The f ol lowi ng appl ies:
L represents an obj ect of type sc_logic.
n represents an obj ect of type int, sc_logic, sc_logic_value_t, bool, char , or int.
NOTEAn implementation is required to supply overloaded operators on sc_logic obj ects to sati sf y therequi rementsof
thi s subcl ause. I t i s unspeci f i ed whether these operators are members of sc_logic, gl obal operators, or provi ded i n some
other way.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


261
Copyright 2012 IEEE. All rights reserved.
7.9.2.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member function scan shall set the val ue by readi ng the next non-white-space character from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member functi on pr int shall write the value as the character li teral ' 0' , ' 1', ' X' , or ' Z' to the specif ied
output stream (see 7.2.10).
7.9.2.8 sc_logic constant definitions
A constant of type sc_logic shal l be defi ned f or each of the four possibl e sc_logic_value_t states. These
constants should be used by appl ications to assign val ues to, or compare values wi th, other sc_logic obj ects,
parti cul arl y i n those cases where an i mpli ci t conversion from a C++ char val ue would be ambi guous.
namespace sc_dt {
const sc_l ogi c SC_LOGI C_0( Log_0 );
const sc_l ogi c SC_LOGI C_1( Log_1 );
const sc_l ogic SC_LOGIC_Z( Log_Z );
const sc_l ogi c SC_LOGI C_X( Log_X );
Table 20sc_logic bitwise and comparison operations
Expr ession Retur n type Oper ation
~L const sc_l ogi c sc_l ogic bi twise complement
L & n const sc_l ogi c sc_l ogi c bi twi se and
n & L const sc_l ogi c sc_l ogi c bi twi se and
L & = n sc_l ogi c& sc_l ogi c assign bi twi se and
L | n const sc_l ogic sc_l ogi c bi twi se or
n | L const sc_l ogic sc_l ogi c bi twi se or
L |= n sc_l ogi c& sc_l ogic assi gn bi twi se or
L ^ n const sc_l ogic sc_l ogic bi twise excl usive or
n^ L const sc_l ogic sc_l ogic bi twise excl usive or
L ^= n sc_l ogi c& sc_l ogi c assi gn bi twi se excl usi ve or
L == n bool test equal
n == L bool test equal
L ! = n bool test not equal
n ! = L bool test not equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


262
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_dt
Exampl e:
sc_core::sc_si gnal <sc_logic> A;
A = '0'; // Error: ambiguous conversion
A = stati c_cast<sc_logic>('0'); // Correct but not recommended
A = SC_LOGIC_0; // Recommended representati on of l ogi c 0
7.9.3 sc_bv_base
7.9.3.1 Description
Cl ass sc_bv_base represents a f inite word-l ength bit vector. I t can be treated as an array of bool or as an
array of sc_logic_value_t (with the restriction that only the states l ogi c 0 and l ogic 1 are l egal). The word
length shall be speci fi ed by a constructor argument or, by def aul t, by the length context object currently in
scope. The word length of an sc_bv_base object shal l be fi xed duri ng instantiati on and shal l not
subsequently be changed.
sc_bv_base is the base class f or the sc_bv class template.
7.9.3.2 Class definition
namespace sc_dt {
class sc_bv_base
{
f riend cl ass sc_lv_base;
publ ic:
// Constructors
expl icit sc_bv_base( i nt nb = sc_length_param().l en() );
expl icit sc_bv_base( bool a, int nb = sc_length_param().l en() );
sc_bv_base( const char* a );
sc_bv_base( const char* a , int nb );
templ ate <cl ass X>
sc_bv_base( const sc_subr ef_r

< X>& a );
templ ate <class T1, class T2>
sc_bv_base( const sc_concr ef_r

<T1,T2> & a );
sc_bv_base( const sc_lv_base& a );
sc_bv_base( const sc_bv_base& a );
// Destructor
virtual ~sc_bv_base();
// Assi gnment operators
templ ate <cl ass X>
sc_bv_base& oper ator = ( const sc_subr ef_r

< X>& a );
templ ate <class T1, class T2>
sc_bv_base& oper ator = ( const sc_concr ef_r

< T1,T2>& a );
sc_bv_base& oper ator = ( const sc_bv_base& a );
sc_bv_base& oper ator = ( const sc_lv_base& a );
sc_bv_base& oper ator = ( const char* a );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


263
Copyright 2012 IEEE. All rights reserved.
sc_bv_base& oper ator = ( const bool* a );
sc_bv_base& oper ator = ( const sc_logic* a );
sc_bv_base& oper ator = ( const sc_unsigned& a );
sc_bv_base& oper ator = ( const sc_si gned& a );
sc_bv_base& oper ator = ( const sc_ui nt_base& a );
sc_bv_base& oper ator = ( const sc_int_base& a );
sc_bv_base& oper ator = ( unsi gned long a );
sc_bv_base& oper ator = ( l ong a );
sc_bv_base& oper ator = ( unsi gned int a );
sc_bv_base& oper ator = ( i nt a );
sc_bv_base& oper ator = ( uint64 a );
sc_bv_base& oper ator = ( i nt64 a );
// Bitwise rotati ons
sc_bv_base& lr otate( i nt n );
sc_bv_base& r rotate( i nt n );
// Bitwise reverse
sc_bv_base& reverse();
// Bit selecti on
sc_bi tref

< sc_bv_base> oper ator [] ( i nt i );


sc_bi tref_r

< sc_bv_base> oper ator [] ( i nt i ) const;


// Part selection
sc_subr ef

< sc_bv_base> oper ator () ( i nt hi , int lo );


sc_subr ef_r

<sc_bv_base> oper ator () ( i nt hi , int lo ) const;


sc_subr ef

< sc_bv_base> r ange( i nt hi , int l o );


sc_subr ef_r

<sc_bv_base> r ange( i nt hi , int l o ) const;


// Reduce f unctions
sc_logi c_value_t and_r educe() const;
sc_logi c_value_t nand_r educe() const;
sc_logi c_value_t or _r educe() const;
sc_logi c_value_t nor_r educe() const;
sc_logi c_value_t xor_reduce() const;
sc_logi c_value_t xnor _reduce() const;
// Common methods
int length() const;
// Expl icit conversions to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


264
Copyright 2012 IEEE. All rights reserved.
bool is_01() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
} ;
} // namespace sc_dt
7.9.3.3 Constraints on usage
Attempti ng to assign the sc_logic_value_t val ues hi gh-impedance or unknown to any el ement of an
sc_bv_base obj ect shall be an error.
The resul t of assigning an array of bool or an array of sc_logic to an sc_bv_base object havi ng a greater
word l ength than the number of array el ements i s undef ined.
7.9.3.4 Constructors
expl icit sc_bv_base( i nt nb = sc_length_param().l en() );
Default constructor sc_bv_base shal l create an sc_bv_base object of word length specif ied by nb
and shal l set the i ni ti al val ue of each element to l ogi c 0. This is the default constructor when nb is
not specif ied (i n whi ch case its value is set by the current l ength context).
expl icit sc_bv_base( bool a , int nb = sc_length_param().len() );
Constructor sc_bv_base shall create an sc_bv_base obj ect of word length speci fi ed by nb. I f nb is
not speci fi ed, the length shal l be set by the current l ength context. The constructor shal l set the i ni ti al
val ue of each el ement to the value of a.
sc_bv_base( const char* a );
Constructor sc_bv_base shall create an sc_bv_base obj ect with an initial value set by the stri ng a.
The word l ength shall be set to the number of characters i n the string.
sc_bv_base( const char* a , int nb );
Constructor sc_bv_base shal l create an sc_bv_base object wi th an i ni ti al val ue set by the stri ng and
word length nb. I f the number of characters i n the string does not match the val ue of nb, the initial
val ue shal l be truncated or zero extended to match the word length.
templ ate <cl ass X> sc_bv_base( const sc_subr ef_r

< X>& a );
templ ate <class T1, class T2> sc_bv_base( const sc_concr ef_r

< T1,T2>& a );
sc_bv_base( const sc_lv_base& a );
sc_bv_base( const sc_bv_base& a );
Constructor sc_bv_base shall create an sc_bv_base obj ect wi th the same word length and value as
a.
NOTEAn implementation may provide a different set of constructors to create an sc_bv_base obj ect f rom an
sc_subr ef_r

< T>, sc_concr ef_r

< T1,T2> , or sc_lv_base obj ect, for exampl e, by provi di ng a cl ass templ ate that i s used
as a common base cl ass f or all these types.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


265
Copyright 2012 IEEE. All rights reserved.
7.9.3.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_bv_base, usi ng truncation or zero-extension, as descri bed in 7.2.1.
7.9.3.6 Explicit type conversion
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
Member function to_str ing shal l perform the conversion to an std::str ing representati on, as
descri bed in 7.2.11. Cal li ng the to_str ing f unction wi th a si ngl e argument i s equivalent to call ing the
to_str ing functi on wi th two arguments, where the second argument i s true.
Call ing the to_str ing f unction wi th no arguments shall create a binary stri ng with a single ' 1' or ' 0'
corresponding to each bit. Thi s string shall not be prefi xed by " 0b" or a leadi ng zero.
Exampl e:
sc_bv_base B(4); // 4-bit vector
B = "0xf "; // Each bi t set to logi c 1
std::stri ng S1 = B.to_stri ng(SC_BIN,f al se); // The contents of S1 wi ll be the stri ng "01111"
std::stri ng S2 = B.to_stri ng(SC_BIN); // The contents of S2 wil l be the stri ng "0b01111"
std::stri ng S3 = B.to_stri ng(); // The contents of S3 wil l be the stri ng "1111"
bool is_01() const;
Member f unction is_01 shall always return true since an sc_bv_base object can only contai n
elements with a val ue of l ogi c 0 or l ogi c 1.
Member f uncti ons that return the integer equi val ent of the bit representation shall be provided to
satisfy the requirements of 7.2.9.
7.9.3.7 Bitwise and comparison operators
Operati ons specif ied i n Table 21 and Table 22 are permi tted. The f ollowi ng applies:
B represents an obj ect of type sc_bv_base.
Vi represents an obj ect of logic vector type sc_bv_base, sc_lv_base, sc_subr ef_r

< T> , or
sc_concr ef_r

< T1,T2> or integer type int, long, unsigned int, unsigned long, sc_signed,
sc_unsigned, sc_int_base, or sc_uint_base.
i represents an obj ect of integer type int.
A represents an array obj ect with el ements of type char , bool, or sc_logic.
The operands may al so be of any other cl ass that i s derived from those just given.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The lef t shi ft operator shal l return a resul t with a word length that i s equal to the word l ength of its
sc_bv_base operand pl us the right (integer) operand. Bits added on the ri ght-hand si de of the resul t shal l be
set to zero.
The right shif t operator returns a resul t wi th a word length that is equal to the word l ength of its sc_bv_base
operand. Bits added on the l ef t-hand side of the resul t shall be set to zero.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


266
Copyright 2012 IEEE. All rights reserved.
I t is an error i f the ri ght operand of a shif t operator i s negative.
sc_bv_base& lr otate( i nt n );
Member f uncti on lr otate shall rotate an sc_bv_base obj ect n places to the l eft.
Table 21sc_bv_base bitwise operations
Expr ession Retur n type Oper ation
B & Vi const sc_l v_base sc_bv_base bi twi se and
Vi & B const sc_l v_base sc_bv_base bi twi se and
B & A const sc_l v_base sc_bv_base bi twi se and
A & B const sc_l v_base sc_bv_base bi twi se and
B & = Vi sc_bv_base& sc_bv_base assi gn bi twi se and
B & = A sc_bv_base& sc_bv_base assi gn bi twi se and
B | Vi const sc_l v_base sc_bv_base bi twi se or
Vi | B const sc_l v_base sc_bv_base bi twi se or
B | A const sc_l v_base sc_bv_base bi twi se or
A | B const sc_l v_base sc_bv_base bi twi se or
B |= Vi sc_bv_base& sc_bv_base assi gn bi twi se or
B |= A sc_bv_base& sc_bv_base assi gn bi twi se or
B ^ Vi const sc_l v_base sc_bv_base bi twi se excl usi ve or
Vi ^ B const sc_l v_base sc_bv_base bi twi se excl usi ve or
B ^ A const sc_l v_base sc_bv_base bi twi se excl usi ve or
A ^ B const sc_l v_base sc_bv_base bi twi se excl usi ve or
B ^= Vi sc_bv_base& sc_bv_base assi gn bi twi se excl usi ve or
B ^= A sc_bv_base& sc_bv_base assi gn bi twi se excl usi ve or
B << i const sc_l v_base sc_bv_base lef t-shif t
B <<= i sc_bv_base& sc_bv_base assi gn l ef t-shif t
B >> i const sc_l v_base sc_bv_base ri ght-shi f t
B >>= i sc_bv_base& sc_bv_base assign ri ght-shi f t
~B const sc_l v_base sc_bv_base bi twi se compl ement
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


267
Copyright 2012 IEEE. All rights reserved.
sc_bv_base& r rotate( i nt n );
Member f uncti on r rotate shal l rotate an sc_bv_base obj ect n places to the ri ght.
sc_bv_base& reverse();
Member f uncti on reverse shall reverse the bi t order in an sc_bv_base object.
NOTEAn implementation is required to supply overloaded operators on sc_bv_base objects to sati sf y the
requi rements of thi s subclause. I t i s unspeci f ied whether these operators are members of sc_bv_base, gl obal operators,
or provi ded i n some other way.
7.9.3.8 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.9.4 sc_lv_base
7.9.4.1 Description
Cl ass sc_lv_base represents a fini te word-length bi t vector. It can be treated as an array of sc_logic_value_t
val ues. The word l ength shall be speci fi ed by a constructor argument or, by default, by the length context
object currently i n scope. The word length of an sc_lv_base object shall be fi xed duri ng instantiati on and
shall not subsequently be changed.
sc_lv_base is the base cl ass for the sc_lv class templ ate.
7.9.4.2 Class definition
namespace sc_dt {
class sc_lv_base
Table 22sc_bv_base comparison operations
Expr ession Retur n type Oper ation
B == Vi bool test equal
Vi == B bool test equal
B == A bool test equal
A == B bool test equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


268
Copyright 2012 IEEE. All rights reserved.
{
f riend cl ass sc_bv_base;
publ ic:
// Constructors
expl icit sc_lv_base( i nt l ength_ = sc_length_param().len() );
expl icit sc_lv_base( const sc_logic& a, int l ength_ = sc_length_param().len() );
sc_lv_base( const char* a );
sc_lv_base( const char* a , i nt l ength_ );
templ ate <cl ass X>
sc_lv_base( const sc_subr ef_r

< X>& a );
templ ate <class T1, class T2>
sc_lv_base( const sc_concr ef_r

<T1,T2>& a );
sc_lv_base( const sc_bv_base& a );
sc_lv_base( const sc_lv_base& a );
// Destructor
virtual ~sc_lv_base();
// Assi gnment operators
templ ate <cl ass X>
sc_l v_base& oper ator = ( const sc_subr ef_r

< X> & a );


templ ate <class T1, class T2>
sc_l v_base& oper ator = ( const sc_concr ef_r

< T1,T2>& a );
sc_l v_base& oper ator = ( const sc_bv_base& a );
sc_l v_base& oper ator = ( const sc_lv_base& a );
sc_l v_base& oper ator = ( const char* a );
sc_l v_base& oper ator = ( const bool* a );
sc_lv_base& oper ator = ( const sc_logic* a );
sc_l v_base& oper ator = ( const sc_unsigned& a );
sc_l v_base& oper ator = ( const sc_si gned& a );
sc_l v_base& oper ator = ( const sc_ui nt_base& a );
sc_l v_base& oper ator = ( const sc_int_base& a );
sc_l v_base& oper ator = ( unsi gned long a );
sc_l v_base& oper ator = ( l ong a );
sc_l v_base& oper ator = ( unsi gned int a );
sc_l v_base& oper ator = ( i nt a );
sc_l v_base& oper ator = ( uint64 a );
sc_l v_base& oper ator = ( i nt64 a );
// Bitwise rotati ons
sc_l v_base& lr otate( i nt n );
sc_l v_base& r rotate( i nt n );
// Bitwise reverse
sc_l v_base& reverse();
// Bit selecti on
sc_bi tref

< sc_bv_base> oper ator [] ( i nt i );


sc_bi tref_r

< sc_bv_base> oper ator [] ( i nt i ) const;


// Part selection
sc_subr ef

< sc_l v_base> oper ator () ( i nt hi , int lo );


sc_subr ef_r

< sc_l v_base> oper ator () ( i nt hi , int lo ) const;


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


269
Copyright 2012 IEEE. All rights reserved.
sc_subr ef

< sc_l v_base> r ange( i nt h i, int l o );


sc_subr ef_r

<sc_l v_base> r ange( i nt hi , int l o ) const;


// Reduce f unctions
sc_logi c_value_t and_r educe() const;
sc_logi c_value_t nand_r educe() const;
sc_logi c_value_t or _r educe() const;
sc_logi c_value_t nor_r educe() const;
sc_logi c_value_t xor_reduce() const;
sc_logi c_value_t xnor _reduce() const;
// Common methods
int length() const;
// Expl icit conversions to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
bool is_01() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
void scan( std::i stream& i s = std::ci n );
} ;
} // namespace sc_dt
7.9.4.3 Constraints on usage
The resul t of assi gni ng an array of bool or an array of sc_logic to an sc_lv_base object having a greater word
length than the number of array el ements is undef ined.
7.9.4.4 Constructors
expl icit sc_lv_base( i nt nb = sc_length_param().l en() );
Constructor sc_lv_base shall create an sc_lv_base obj ect of word length specif ied by nb and shal l
set the i nitial value of each element to l ogi c 0. This i s the def aul t constructor when nb i s not
specif ied (i n whi ch case its val ue shal l be set by the current length context).
expl icit sc_lv_base( bool a, int nb = sc_length_param().len() );
Constructor sc_lv_base shall create an sc_lv_base obj ect of word length specif ied by nb and shal l
set the initial value of each element to the val ue of a. I f nb i s not specif ied, the l ength shal l be set by
the current l ength context.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


270
Copyright 2012 IEEE. All rights reserved.
sc_lv_base( const char* a);
Constructor sc_l v_base shall createan sc_l v_base obj ect wi th an i nitial val ueset by thestri ng li teral
a. Thewordl engthshal l beset tothenumber of charactersi n thestri ng l iteral .
sc_lv_base( const char* a, int nb );
Constructor sc_l v_base shall createan sc_l v_base obj ect wi th an i nitial val ueset by thestri ng li teral
and word length nb. If thenumber of characters in thestri ng l iteral does not match thevalueof nb,
theini ti al valueshall betruncated or zero extendedto matchthewordl ength.
templ ate<cl assX> sc_l v_base( const sc_subr ef_r

< X> & a);


templ ate<classT1, classT2> sc_l v_base( const sc_concr ef_r

< T1,T2> & a);


sc_l v_base( const sc_bv_base& a);
Constructor sc_l v_base shall createansc_l v_base obj ect wi th thesameword l engthandvalueasa.
sc_l v_base( const sc_l v_base& a);
Constructor sc_l v_base shall createansc_l v_base obj ect wi th thesameword l engthandvalueasa.
NOTEAn implementation may provide a different set of constructors to create an sc_lv_base object from an
sc_subr ef_r

< T>, sc_concr ef_r

, or sc_bv_base object, for example, by providing a class template that is used as a


common baseclass for all thesetypes.
7.9.4.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion from SystemC data types and the nati ve C++
integer representati ontosc_l v_base, usi ng truncation or zero-extension, asdescri bed in 7.2.1.
7.9.4.6 Explicit type conversion
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep) const;
const std::string to_str ing( sc_numrep, bool ) const;
Member functi on to_str ing shall performaconversi onto anstd::str ing representati on, asdescri bed
in 7.2.11. Call ing theto_str ing function wi th asi ngl eargument i sequivalent to call ing theto_str ing
functi on with two arguments, where the second argument is true. Attempting to call the si ngl e or
doubl eargument to_str ing functi on for an sc_l v_base object with one or more elementsset to the
high-i mpedanceor unknown stateshal l bean error.
Call ing theto_str ing function with no arguments shall createa logic val ue stri ng wi th asingle '1',
'0' , 'Z ', or 'X ' corresponding to each bi t. Thisstring shal l not beprefi xed by " 0b" or al eading zero.
Exampl e:
sc_lv_baseL(4); // 4-bit vector
L = "0xf"; // Each bi t set to logic 1
std::stri ngS1 = L.to_stri ng(SC_BIN,fal se); // Thecontentsof S1 wil l bethestring "01111"
std::stri ngS2 = L.to_stri ng(SC_BIN); // Thecontentsof S2 wil l bethestring "0b01111"
std::stri ngS3 = L.to_stri ng(); // Thecontentsof S3 wil l bethestri ng "1111"
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


271
Copyright 2012 IEEE. All rights reserved.
bool is_01() const;
Member f uncti on is_01 shall return true onl y when every element of an sc_lv_base obj ect has a
val ue of l ogi c 0 or l ogic 1. If any element has the val ue hi gh-impedance or unknown, it shal l return
false.
Member f uncti ons that return the integer equi val ent of the bit representation shall be provided to
satisfy the requirements of 7.2.9. Call ing any such integer conversi on function f or an obj ect havi ng
one or more bi ts set to the hi gh-impedance or unknown state shal l be an error.
7.9.4.7 Bitwise and comparison operators
Operati ons specif ied i n Table 23 and Table 24 are permi tted. The f ollowi ng applies:
L represents an obj ect of type sc_lv_base.
Vi represents an obj ect of logic vector type sc_bv_base, sc_lv_base, sc_subr ef_r

< T> , or
sc_concr ef_r

< T1,T2>, or integer type int, long, unsigned int, unsigned long, sc_signed,
sc_unsigned, sc_int_base, or sc_uint_base.
i represents an obj ect of integer type int.
A represents an array obj ect with el ements of type char , bool, or sc_logic.
The operands may al so be of any other cl ass that i s derived from those just given.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The lef t shi ft operator shal l return a resul t with a word length that i s equal to the word l ength of its
sc_lv_base operand plus the right (i nteger) operand. Bi ts added on the ri ght-hand si de of the resul t shall be
set to zero.
The ri ght shi ft operator shal l return a resul t wi th a word length that i s equal to the word length of i ts
sc_lv_base operand. Bits added on the l eft-hand side of the result shall be set to zero.
I t is an error i f the ri ght operand of a shif t operator i s negative.
sc_l v_base& lr otate( i nt n );
Member f uncti on lr otate shall rotate an sc_lv_base obj ect n places to the left.
sc_l v_base& r rotate( i nt n );
Member f uncti on r rotate shal l rotate an sc_lv_base object n places to the ri ght.
sc_l v_base& reverse();
Member f uncti on reverse shall reverse the bi t order in an sc_lv_base obj ect.
NOTEAn implementation i s requi red to suppl y overl oaded operators on sc_lv_base obj ects to sati sf y the
requi rements of this subcl ause. I t i s unspeci f i ed whether these operators are members of sc_lv_base, gl obal operators, or
provi ded i n some other way.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


272
Copyright 2012 IEEE. All rights reserved.
Table 23sc_lv_base bitwise operations
Expr ession Retur n type Oper ation
L & Vi const sc_l v_base sc_l v_base bi twi se and
Vi & L const sc_l v_base sc_l v_base bi twi se and
L & A const sc_l v_base sc_l v_base bi twi se and
A & L const sc_l v_base sc_l v_base bi twi se and
L & = Vi sc_l v_base& sc_l v_base assign bi twi se and
L & = A sc_l v_base& sc_l v_base assign bi twi se and
L | Vi const sc_l v_base sc_l v_base bitwi se or
Vi | L const sc_l v_base sc_l v_base bitwi se or
L | A const sc_l v_base sc_l v_base bi twi se or
A | L const sc_l v_base sc_l v_base bi twi se or
L |= Vi sc_l v_base& sc_l v_base assi gn bi twi se or
L |= A sc_l v_base& sc_l v_base assi gn bi twi se or
L ^ Vi const sc_l v_base sc_l v_base bi twi se excl usi ve or
Vi ^ L const sc_l v_base sc_l v_base bi twi se excl usi ve or
L ^ A const sc_l v_base sc_l v_base bi twi se excl usi ve or
A ^ L const sc_l v_base sc_l v_base bi twi se excl usi ve or
L ^= Vi sc_l v_base& sc_l v_base assign bi twi se excl usi ve or
L ^= A sc_l v_base& sc_l v_base assign bi twi se excl usi ve or
L << i const sc_l v_base sc_l v_base l eft-shi f t
L <<= i sc_l v_base& sc_l v_base assi gn l ef t-shi ft
L >> i const sc_l v_base sc_l v_base ri ght-shif t
L >>= i sc_l v_base& sc_l v_base assi gn ri ght-shi ft
~L const sc_l v_base sc_l v_base bi twi se complement
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


273
Copyright 2012 IEEE. All rights reserved.
7.9.4.8 Other member functions
void scan( std::i stream& i s = std::ci n );
Member functi on scan shall set the value by reading the next formatted character stri ng from the
specif ied input stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l write the val ue as a f ormatted character string to the specif ied output
stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length (see 7.2.4).
7.9.5 sc_bv
7.9.5.1 Description
Class template sc_bv represents a f inite word-l ength bi t vector. I t can be treated as an array of bool or as an
array of sc_logic_value_t values (wi th the restricti on that onl y the states l ogi c 0 and logic 1 are legal ). The
word l ength shal l be speci fi ed by a templ ate argument.
Any publ ic member functi ons of the base cl ass sc_bv_base that are overridden in class sc_bv shal l have the
same behavior in the two cl asses. Any publ ic member f uncti ons of the base class not overridden i n this way
shall be publi cl y i nherited by cl ass sc_bv.
7.9.5.2 Class definition
namespace sc_dt {
templ ate <i nt W>
class sc_bv
: publi c sc_bv_base
{
publ ic:
// Constructors
sc_bv();
expl icit sc_bv( bool i nit_value );
expl icit sc_bv( char ini t_val ue );
sc_bv( const char* a );
Table 24sc_lv_base comparison operations
Expr ession Retur n type Oper ation
L == Vi bool test equal
Vi == L bool test equal
L == A bool test equal
A == L bool test equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


274
Copyright 2012 IEEE. All rights reserved.
sc_bv( const bool* a );
sc_bv( const sc_logic* a );
sc_bv( const sc_unsigned& a );
sc_bv( const sc_si gned& a );
sc_bv( const sc_uint_base& a );
sc_bv( const sc_int_base& a );
sc_bv( unsigned long a );
sc_bv( l ong a );
sc_bv( unsigned i nt a );
sc_bv( i nt a );
sc_bv( ui nt64 a );
sc_bv( i nt64 a );
templ ate <cl ass X>
sc_bv( const sc_subr ef_r

< X> & a );


templ ate <class T1, class T2>
sc_bv( const sc_concr ef_r

< T1,T2> & a );


sc_bv( const sc_bv_base& a );
sc_bv( const sc_lv_base& a );
sc_bv( const sc_bv<W>& a );
// Assi gnment operators
templ ate <cl ass X>
sc_bv<W>& oper ator = ( const sc_subr ef_r

< X>& a );
templ ate <class T1, class T2>
sc_bv<W>& oper ator = ( const sc_concr ef_r

< T1,T2>& a );
sc_bv<W>& oper ator = ( const sc_bv_base& a );
sc_bv<W>& oper ator = ( const sc_lv_base& a );
sc_bv<W>& oper ator = ( const sc_bv<W>& a );
sc_bv<W>& oper ator = ( const char* a );
sc_bv<W>& oper ator = ( const bool* a );
sc_bv<W>& oper ator = ( const sc_logic* a );
sc_bv<W>& oper ator = ( const sc_unsigned& a );
sc_bv<W>& oper ator = ( const sc_si gned& a );
sc_bv<W>& oper ator = ( const sc_ui nt_base& a );
sc_bv<W>& oper ator = ( const sc_int_base& a );
sc_bv<W>& oper ator = ( unsi gned long a );
sc_bv<W>& oper ator = ( l ong a );
sc_bv<W>& oper ator = ( unsi gned int a );
sc_bv<W>& oper ator = ( i nt a );
sc_bv<W>& oper ator = ( uint64 a );
sc_bv<W>& oper ator = ( i nt64 a );
} ;
} // namespace sc_dt
7.9.5.3 Constraints on usage
Attempti ng to assign the sc_logic_value_t val ues hi gh-impedance or unknown to any el ement of an sc_bv
object shall be an error.
The result of assigning an array of bool or an array of sc_logic to an sc_bv obj ect havi ng a greater word
length than the number of array el ements is undef ined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


275
Copyright 2012 IEEE. All rights reserved.
7.9.5.4 Constructors
sc_bv();
The def aul t constructor sc_bv shal l create an sc_bv object of word length specif ied by the template
argument W, and it shall set the i ni ti al val ue of every el ement to logic 0.
The other constructors shall create an sc_bv object of word length speci fi ed by the templ ate argument W
and value correspondi ng to the constructor argument. If the word length of a data type or stri ng l iteral
argument di ff ers f rom the template argument, truncati on or zero-extensi on shal l be appli ed, as described i n
7.2.1. I f the number of elements in an array of bool or array of sc_logic used as the constructor argument i s
less than the word length, the initial value of al l el ements shall be undef ined.
NOTEAn implementation may provide a di f f erent set of constructors to create an sc_bv obj ect f rom an
sc_subr ef_r

< T>, sc_concr ef_r

< T1,T2>, sc_bv_base, or sc_lv_base obj ect, for example, by provi ding a cl ass
templ ate that i s used as a common base cl ass f or al l these types.
7.9.5.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representati on to sc_bv, usi ng truncation or zero-extension, as descri bed i n 7.2.1. The excepti on is
assignment of an array of bool or an array of sc_logic to an sc_bv object, as descri bed in 7.9.5.4.
7.9.6 sc_lv
7.9.6.1 Description
Class template sc_lv represents a f inite word-l ength bi t vector. I t can be treated as an array of
sc_logic_value_t val ues. The word l ength shal l be specif ied by a template argument.
Any publi c member functions of the base cl ass sc_lv_base that are overri dden in cl ass sc_lv shall have the
same behavior in the two cl asses. Any publ ic member f uncti ons of the base class not overridden i n this way
shall be publi cl y i nherited by cl ass sc_lv.
7.9.6.2 Class definition
namespace sc_dt {
templ ate <i nt W>
class sc_lv
: publi c sc_l v_base
{
publ ic:
// Constructors
sc_lv();
expl icit sc_lv( const sc_logic& i ni t_value );
expl icit sc_lv( bool i ni t_value );
expl icit sc_lv( char ini t_val ue );
sc_lv( const char* a );
sc_lv( const bool * a );
sc_lv( const sc_logic* a );
sc_lv( const sc_unsi gned& a );
sc_lv( const sc_si gned& a );
sc_lv( const sc_uint_base& a );
sc_lv( const sc_int_base& a );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


276
Copyright 2012 IEEE. All rights reserved.
sc_lv( unsigned l ong a );
sc_lv( l ong a );
sc_lv( unsigned i nt a );
sc_lv( i nt a );
sc_lv( ui nt64 a );
sc_lv( i nt64 a );
templ ate <cl ass X>
sc_lv( const sc_subr ef_r

< X>& a );
template <class T1, cl ass T2>
sc_lv( const sc_concr ef_r

< T1,T2>& a );
sc_lv( const sc_bv_base& a );
sc_lv( const sc_lv_base& a );
sc_lv( const sc_lv<W>& a );
// Assi gnment operators
templ ate <cl ass X>
sc_lv<W>& oper ator = ( const sc_subr ef_r

< X> & a );


template <class T1, cl ass T2>
sc_lv<W>& oper ator = ( const sc_concr ef_r

< T1,T2> & a );


sc_lv<W>& oper ator = ( const sc_bv_base& a );
sc_lv<W>& oper ator = ( const sc_lv_base& a );
sc_lv<W>& oper ator = ( const sc_lv<W>& a );
sc_lv<W>& oper ator = ( const char* a );
sc_lv<W>& oper ator = ( const bool* a );
sc_lv<W>& oper ator = ( const sc_logic* a );
sc_l v<W>& oper ator = ( const sc_unsigned& a );
sc_lv<W>& oper ator = ( const sc_si gned& a );
sc_lv<W>& oper ator = ( const sc_ui nt_base& a );
sc_lv<W>& oper ator = ( const sc_int_base& a );
sc_lv<W>& oper ator = ( unsi gned long a );
sc_lv<W>& oper ator = ( l ong a );
sc_lv<W>& oper ator = ( unsi gned int a );
sc_lv<W>& oper ator = ( i nt a );
sc_lv<W>& oper ator = ( uint64 a );
sc_lv<W>& oper ator = ( i nt64 a );
} ;
} // namespace sc_dt
7.9.6.3 Constraints on usage
The result of assigning an array of bool or an array of sc_logic to an sc_lv obj ect having a greater word
length than the number of array el ements is undef ined.
7.9.6.4 Constructors
sc_lv();
Default constructor sc_lv shal l create an sc_lv object of word length specif ied by the template
argument W and shal l set the i nitial value of every element to unknown.
The other constructors shall create an sc_lv obj ect of word l ength specifi ed by the templ ate argument W and
val ue corresponding to the constructor argument. If the word l ength of a data type or string li teral argument
dif fers f rom the templ ate argument, truncati on or zero-extension shall be appl ied, as described in 7.2.1. If
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


277
Copyright 2012 IEEE. All rights reserved.
the number of elements in an array of bool or array of sc_logic used as the constructor argument is less than
the word length, the initial value of all el ements shall be undef ined.
NOTEAn implementation may provide a different set of constructors to create an sc_lv obj ect f rom an
sc_subr ef_r

< T>, sc_concr ef_r

< T1,T2>, sc_bv_base, or sc_lv_base obj ect, for example, by provi ding a cl ass
templ ate that i s used as a common base cl ass f or al l these types.
7.9.6.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to sc_lv, using truncation or zero-extensi on, as described in 7.2.1. The excepti on is
assignment f rom an array of bool or an array of sc_logic to an sc_lv obj ect, as descri bed in 7.9.6.4.
7.9.7 Bit-selects
7.9.7.1 Description
Class template sc_bi tref_r

< T> represents a bit selected f rom a vector used as an rvalue.


Class template sc_bi tref

< T> represents a bit selected f rom a vector used as an l value.


The use of the term vector here includes part-selects and concatenati ons of bi t vectors and l ogi c vectors.
The templ ate parameter is the name of the cl ass accessed by the bi t-select.
7.9.7.2 Class definition
namespace sc_dt {
templ ate <class T>
class sc_bi tref_r

{
f riend cl ass sc_bv_base;
f riend cl ass sc_lv_base;
publ ic:
// Copy constructor
sc_bi tref_r

( const sc_bi tref_r

< T>& a );
// Bitwise compl ement
const sc_l ogi c oper ator ~ () const;
// Impl icit conversi on to sc_logic
oper ator const sc_logic() const;
// Expl icit conversions
bool is_01() const;
bool to_bool() const;
char to_char() const;
// Common methods
int length() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


278
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_bi tref_r

();
sc_bi tref_r

< T> & oper ator = ( const sc_bi tref_r

< T> & );


} ;
// -------------------------------------------------------------
templ ate <class T>
class sc_bi tref

: publi c sc_bi tref_r

< T>
{
f riend cl ass sc_bv_base;
f riend cl ass sc_lv_base;
publ ic:
// Copy constructor
sc_bi tref

( const sc_bi tref

< T>& a );
// Assi gnment operators
sc_bi tref

< T>& oper ator = ( const sc_bi tref_r

< T>& a );
sc_bi tref

< T>& oper ator = ( const sc_bi tref

< T> & a );


sc_bi tref

< T>& oper ator = ( const sc_logic& a );


sc_bi tref

< T>& oper ator = ( sc_l ogic_value_t v );


sc_bi tref

< T>& oper ator = ( bool a );


sc_bi tref

< T>& oper ator = ( char a );


sc_bi tref

< T>& oper ator = ( i nt a );


// Bitwise assi gnment operators
sc_bi tref

< T>& oper ator & = ( const sc_bi tref_r

< T>& a );
sc_bi tref

< T>& oper ator & = ( const sc_logic& a );


sc_bi tref

< T>& oper ator & = ( sc_l ogic_value_t v );


sc_bi tref

< T>& oper ator & = ( bool a );


sc_bi tref

< T>& oper ator & = ( char a );


sc_bi tref

< T>& oper ator & = ( i nt a );


sc_bi tref

< T>& oper ator |= ( const sc_bi tref_r

< T>& a );
sc_bi tref

< T>& oper ator |= ( const sc_logic& a );


sc_bi tref

< T>& oper ator |= ( sc_l ogi c_value_t v );


sc_bi tref

< T>& oper ator |= ( bool a );


sc_bi tref

< T>& oper ator |= ( char a );


sc_bi tref

< T>& oper ator |= ( i nt a );


sc_bi tref

< T>& oper ator ^= ( const sc_bi tref_r

< T>& a );
sc_bi tref

< T>& oper ator ^= ( const sc_logic& a );


sc_bi tref

< T>& oper ator ^= ( sc_l ogic_value_t v );


sc_bi tref

< T>& oper ator ^= ( bool a );


sc_bi tref

< T>& oper ator ^= ( char a );


sc_bi tref

< T>& oper ator ^= ( i nt a );


// Other methods
voi d scan( std::i stream& i s = std::ci n );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


279
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_bitref();
} ;
} // namespace sc_dt
7.9.7.3 Constraints on usage
Bi t-select objects shal l only be created using the bit-select operators of an sc_bv_base or sc_lv_base object
(or an instance of a class deri ved f rom sc_bv_base or sc_lv_base) or a part-select or concatenation thereof,
as described i n 7.2.6.
An appl ication shall not expli citl y create an i nstance of any bi t-sel ect class.
An appl ication should not decl are a reference or pointer to any bit-sel ect obj ect.
I t is strongly recommended that an appl ication avoi d the use of a bi t-sel ect as the return type of a f unction
because the l if etime of the obj ect to whi ch the bi t-select ref ers may not extend beyond the f uncti on return
statement.
Exampl e:
sc_dt::sc_bi tref <sc_bv_base> get_bit_n(sc_bv_base bv, i nt n) {
return bv[ n]; // Unsaf e: returned bit-select references local variable
}
7.9.7.4 Assignment operators
Overl oaded assignment operators for the lval ue bit-select shall provide conversi on to sc_logic_value_t
val ues. The assi gnment operator for the rvalue bit-sel ect shal l be declared as private to prevent i ts use by an
appl ication.
7.9.7.5 Implicit type conversion
oper ator const sc_logic() const;
Operator sc_logic shal l create an sc_logic object with the same value as the bit-sel ect.
7.9.7.6 Explicit type conversion
char to_char() const;
Member f uncti on to_char shall convert the bi t-select val ue to the char equi val ent.
bool to_bool() const;
Member function to_bool shall convert the bit-select value to false or true. I t shall be an error to call
thi s f unction i f the sc_logic val ue i s not l ogi c 0 or l ogi c 1.
bool is_01() const;
Member functi on is_01 shall return true i f the sc_logic value i s logic 0 or logic 1; otherwi se, the
return val ue shal l be false.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


280
Copyright 2012 IEEE. All rights reserved.
7.9.7.7 Bitwise and comparison operators
Operati ons specif ied i n Tabl e 25 are permitted. The foll owing appl ies:
B represents an obj ect of type sc_bi tref_r

< T> (or any derived cl ass).


NOTEAn implementation is required to suppl y overl oaded operators on sc_bi tr ef_r

< T> obj ects to sati sf y the


requi rements of thi s subcl ause. I t i s unspeci f i ed whether these operators are members of sc_bi tr ef_r

< T> , gl obal


operators, or provi ded in some other way.
7.9.7.8 Other member functions
void scan( std::i stream& i s = std::ci n );
Member f unction scan shal l set the value of the bit referenced by an lvalue bit-sel ect. The val ue
shal l correspond to the C++ bool val ue obtai ned by reading the next formatted character string from
the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member function pr int shal l print the value of the bi t referenced by the bi t-select to the speci fi ed
output stream (see 7.2.10). The formatti ng shal l be i mplementati on-defi ned but shall be equi val ent
to pri nti ng the val ue returned by member functi on to_bool.
int length() const;
Member f uncti on length shall unconditi onal ly return a word l ength of 1 (see 7.2.4).
7.9.8 Part-selects
7.9.8.1 Description
Class template sc_subr ef_r

< T> represents a part-select f rom a vector used as an rvalue.


Class template sc_subr ef

< T> represents a part-sel ect f rom a vector used as an lvalue.


The use of the term vector here includes part-selects and concatenati ons of bi t vectors and l ogi c vectors.
The templ ate parameter is the name of the class accessed by the part-sel ect.
Table 25sc_bitref_r

<T> bitwise and comparison operations


Expr ession Retur n type Oper ation
B & B const sc_l ogi c sc_bi tr ef_r

< T> bi twi se and


B | B const sc_l ogi c sc_bi tr ef_r

< T> bi twi se or


B ^ B const sc_l ogic sc_bi tr ef_r

< T> bi twi se excl usi ve or


B == B bool test equal
B ! = B bool test not equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


281
Copyright 2012 IEEE. All rights reserved.
The set of operations that can be perf ormed on a part-select shall be i dentical to that of i ts associated vector
(subject to the constrai nts that appl y to rvalue objects).
7.9.8.2 Class definition
namespace sc_dt {
templ ate <class T>
class sc_subr ef_r

{
publ ic:
// Copy constructor
sc_subr ef_r

( const sc_subr ef_r

< T>& a );
// Bit selecti on
sc_bi tref_r

<sc_subr ef_r

< T> > oper ator [] ( i nt i ) const;


// Part selection
sc_subr ef_r

< sc_subref_r

< T> > oper ator () ( i nt hi , int l o ) const;


sc_subr ef_r

< sc_subref_r

< T> > r ange( i nt hi , int lo ) const;


// Reduce f unctions
sc_logi c_value_t and_r educe() const;
sc_logi c_value_t nand_r educe() const;
sc_logi c_value_t or _r educe() const;
sc_logi c_value_t nor_r educe() const;
sc_logi c_value_t xor_reduce() const;
sc_logi c_value_t xnor _reduce() const;
// Common methods
int length() const;
// Expl icit conversions to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
bool is_01() const;
// Other methods
void pr int( std::ostream& os = std::cout ) const;
bool reversed() const;
pri vate:
// Di sabl ed
sc_subr ef_r

();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


282
Copyright 2012 IEEE. All rights reserved.
sc_subr ef_r

< T>& oper ator = ( const sc_subr ef_r

< T>& );
} ;
// -------------------------------------------------------------
templ ate <class T>
class sc_subr ef

: publi c sc_subr ef_r

< T>
{
publ ic:
// Copy constructor
sc_subr ef

( const sc_subr ef

< T>& a );
// Assi gnment operators
templ ate <class T>
sc_subr ef

< T>& oper ator = ( const sc_subr ef_r

< T> & a );


templ ate <class T1, class T2>
sc_subr ef

< T>& oper ator = ( const sc_concr ef_r

< T1,T2>& a );
sc_subr ef

< T>& oper ator = ( const sc_bv_base& a );


sc_subr ef

< T>& oper ator = ( const sc_lv_base& a );


sc_subr ef

< T>& oper ator = ( const sc_subr ef_r

< T> & a );


sc_subr ef

< T>& oper ator = ( const sc_subr ef

< T>& a );
sc_subr ef

< T>& oper ator = ( const char* a );


sc_subr ef

< T>& oper ator = ( const bool* a );


sc_subr ef

< T>& oper ator = ( const sc_logic* a );


sc_subr ef

< T>& oper ator = ( const sc_unsigned& a );


sc_subr ef

< T>& oper ator = ( const sc_si gned& a );


sc_subr ef

< T>& oper ator = ( const sc_ui nt_base& a );


sc_subr ef

< T>& oper ator = ( const sc_int_base& a );


sc_subr ef

< T>& oper ator = ( unsi gned long a );


sc_subr ef

< T>& oper ator = ( l ong a );


sc_subr ef

< T>& oper ator = ( unsi gned int a );


sc_subr ef

< T>& oper ator = ( i nt a );


sc_subr ef

< T>& oper ator = ( uint64 a );


sc_subr ef

< T>& oper ator = ( i nt64 a );


// Bitwise rotati ons
sc_subr ef

< T>& lr otate( i nt n );


sc_subr ef

< T>& r rotate( i nt n );


// Bitwise reverse
sc_subr ef

< T>& reverse();


// Bit selection
sc_bi tref

< sc_subref

< T> > oper ator [] ( i nt i );


// Part selection
sc_subr ef

< sc_subref

< T> > oper ator () ( i nt hi , int lo );


sc_subr ef

< sc_subref

< T> > r ange( i nt hi , int lo );


// Other methods
void scan( std::i stream& = std::cin );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


283
Copyright 2012 IEEE. All rights reserved.
pri vate:
// Di sabl ed
sc_subr ef

();
} ;
} // namespace sc_dt
7.9.8.3 Constraints on usage
Part-sel ect objects shall only be created using the part-select operators of an sc_bv_base or sc_lv_base
object (or an i nstance of a class derived from sc_bv_base or sc_lv_base) or a part-sel ect or concatenati on
thereof , as described in 7.2.6.
An appl ication shall not expli citl y create an i nstance of any part-select class.
An appl ication should not decl are a reference or pointer to any part-sel ect obj ect.
An rvalue part-select shal l not be used to modif y the vector wi th which it is associ ated.
I t i s strongly recommended that an appli cation avoi d the use of a part-select as the return type of a functi on
because the li feti me of the obj ect to which the part-select refers may not extend beyond the functi on return
statement.
Exampl e:
sc_dt::sc_subref<sc_bv_base> get_byte(sc_bv_base bv, i nt pos) {
return bv(pos+7,pos); // Unsafe: returned part-select ref erences l ocal vari abl e
}
7.9.8.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to l val ue part-selects. If the size of a data type or string l iteral operand dif fers from the
part-sel ect word l ength, truncation or zero-extensi on shall be used, as described in 7.2.1. If an array of bool
or array of sc_logic is assi gned to a part-sel ect and i ts number of elements i s less than the part-select word
length, the val ue of the part-sel ect shall be undefi ned.
The default assi gnment operator for an rvalue part-select i s pri vate to prevent its use by an appl ication.
7.9.8.5 Explicit type conversion
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
Member f unction to_str ing shal l convert to an std::str ing representation, as described i n 7.2.11.
Call ing the to_str ing f uncti on with a single argument is equi valent to call ing the to_str ing f uncti on
wi th two arguments, where the second argument i s true. Attempti ng to cal l the si ngl e or doubl e
argument to_str ing function for a part-select wi th one or more elements set to the hi gh-impedance
or unknown state shall be an error.
Call ing the to_str ing function with no arguments shall create a logic val ue stri ng wi th a single '1',
'0' , 'Z ' , or 'X ' corresponding to each bit. Thi s string shall not pref ixed by " 0b" or a leadi ng zero.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


284
Copyright 2012 IEEE. All rights reserved.
bool is_01() const;
Member f uncti on is_01 shall return true onl y when every element of a part-select has a value of
logi c 0 or logi c 1. If any el ement has the value hi gh-impedance or unknown, i t shal l return fal se.
Member f uncti ons that return the integer equi val ent of the bit representation shall be provided to
satisfy the requirements of 7.2.9. Call ing any such integer conversi on function f or an obj ect havi ng
one or more bi ts set to the hi gh-impedance or unknown state shal l be an error.
7.9.8.6 Bitwise and comparison operators
Operati ons specif ied i n Table 26 and Table 28 are permitted for al l vector part-selects. Operations specif ied
in Table 27 are permi tted for lvalue vector part-sel ects only. The f ol lowi ng applies:
P represents an lvalue or rvalue vector part-sel ect.
L represents an lvalue vector part-sel ect.
Vi represents an obj ect of logic vector type sc_bv_base, sc_l v_base, sc_subr ef_r

< T>, or
sc_concr ef_r

< T1,T2>, or i nteger type int, l ong, unsi gned int, unsi gned long, sc_signed,
sc_unsi gned, sc_i nt_base, or sc_uint_base.
i represents an obj ect of integer type int.
A represents an array obj ect with el ements of type char , bool , or sc_l ogi c.
The operands may al so be of any other cl ass that i s derived from those just given.
Table 26sc_subref_r

<T> bitwise operations


Expr ession Retur n type Oper ation
P & Vi const sc_l v_base sc_subr ef_r

< T> bi twi se and


Vi & P const sc_l v_base sc_subr ef_r

< T> bi twi se and


P & A const sc_l v_base sc_subr ef_r

< T> bi twi se and


A & P const sc_l v_base sc_subr ef_r

< T> bi twi se and


P | Vi const sc_l v_base sc_subr ef_r

< T> bi twi se or


Vi | P const sc_l v_base sc_subr ef_r

< T> bi twi se or


P | A const sc_l v_base sc_subr ef_r

< T> bi twi se or


A | P const sc_l v_base sc_subr ef_r

< T> bi twi se or


P ^ Vi const sc_l v_base sc_subr ef_r

< T> bi twi se excl usi ve or


Vi ^ P const sc_l v_base sc_subr ef_r

< T> bi twi se excl usi ve or


P ^ A const sc_l v_base sc_subr ef_r

< T> bi twi se excl usi ve or


A ^ P const sc_l v_base sc_subr ef_r

< T> bi twi se excl usi ve or


P << i const sc_l v_base sc_subr ef_r

< T> l ef t-shi f t


P >> i const sc_l v_base sc_subr ef_r

< T> ri ght-shi f t


~P const sc_l v_base sc_subr ef_r

< T> bi twi se compl ement


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


285
Copyright 2012 IEEE. All rights reserved.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The left shif t operator shal l return a result with a word length that i s equal to the word length of its part-
sel ect operand plus the right (integer) operand. Bits added on the ri ght-hand si de of the resul t shall be set to
zero.
The right shif t operator shall return a resul t wi th a word length that i s equal to the word l ength of i ts part-
sel ect operand. Bi ts added on the left-hand si de of the result shal l be set to zero.
I t is an error i f the ri ght operand of a shif t operator i s negative.
sc_subr ef

< T>& lr otate( i nt n );


Member f uncti on lr otate shall rotate an lvalue part-select n places to the left.
sc_subr ef

< T>& r rotate( i nt n );


Member f uncti on r rotate shal l rotate an lvalue part-select n pl aces to the ri ght.
Table 27sc_subref

<T> bitwise operations


Expr ession Retur n type Oper ation
L & = Vi sc_subr ef_r

< T> & sc_subr ef_r

< T> assign bi twi se and


L & = A sc_subr ef_r

< T> & sc_subr ef_r

< T> assign bi twi se and


L |= Vi sc_subr ef_r

< T> & sc_subr ef_r

< T> assi gn bi twi se or


L |= A sc_subr ef_r

< T> & sc_subr ef_r

< T> assi gn bi twi se or


L ^= Vi sc_subr ef_r

< T> & sc_subr ef_r

< T> assign bi twi se excl usi ve or


L ^= A sc_subr ef_r

< T> & sc_subr ef_r

< T> assign bi twi se excl usi ve or


L <<= i sc_subr ef_r

< T> & sc_subr ef_r

< T> assign lef t-shif t


L >>= i sc_subr ef_r

< T> & sc_subr ef_r

< T> assi gn ri ght-shi f t


Table 28sc_subref_r

<T> comparison operations


Expr ession Retur n type Oper ation
P == Vi bool test equal
Vi == P bool test equal
P == A bool test equal
A == P bool test equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


286
Copyright 2012 IEEE. All rights reserved.
sc_subr ef

< T>& reverse();


Member f uncti on reverse shal l reverse the bit order in an lvalue part-select.
NOTEAn implementation is required to suppl y overl oaded operators on sc_subr ef_r

< T> and sc_subr ef

< T> obj ects


to sati sf y the requirements of thi s subcl ause. I t i s unspeci f i ed whether these operators are members of sc_subr ef

< T> ,
members of sc_subr ef

< T> , global operators, or provi ded i n some other way.


7.9.8.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member function scan shal l set the values of the bi ts ref erenced by an lvalue part-select by reading
the next formatted character string from the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member functi on pr int shall print the val ues of the bi ts referenced by the part-sel ect to the specif ied
output stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length of the part-select (see 7.2.4).
bool reversed() const;
Member functi on rever sed shall return true if the el ements of a part-select are i n the reverse order
to those of i ts associated vector (if the lef t-hand index used to form the part-select i s l ess than the
right-hand index); otherwi se, the return value shall be false.
7.9.9 Concatenations
7.9.9.1 Description
Class templ ate sc_concr ef_r

< T1,T2> represents a concatenation of bi ts f rom one or more vector used as an


rvalue.
Class templ ate sc_concr ef

< T1,T2> represents a concatenation of bi ts from one or more vector used as an


lvalue.
The use of the term vector here includes part-selects and concatenati ons of bi t vectors and l ogi c vectors.
The template parameters are the class names of the two vectors used to create the concatenati on.
The set of operati ons that can be performed on a concatenation shal l be i denti cal to that of its associated
vectors (subj ect to the constraints that appl y to rvalue objects).
7.9.9.2 Class definition
namespace sc_dt {
templ ate <class T1, class T2>
class sc_concr ef_r

{
publ ic:
// Copy constructor
sc_concr ef_r

( const sc_concr ef_r

< T1,T2>& a );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


287
Copyright 2012 IEEE. All rights reserved.
// Destructor
virtual ~sc_concr ef_r

();
// Bit selecti on
sc_bi tref_r

<sc_concr ef_r

< T1,T2> > oper ator [] ( i nt i ) const;


// Part sel ection
sc_subr ef_r

< sc_concr ef_r

< T1,T2> > oper ator () ( i nt hi , int l o ) const;


sc_subr ef_r

< sc_concr ef_r

< T1,T2> > r ange( i nt hi , int lo ) const;


// Reduce f unctions
sc_logi c_value_t and_r educe() const;
sc_logi c_value_t nand_r educe() const;
sc_logi c_value_t or _r educe() const;
sc_logi c_value_t nor_r educe() const;
sc_logi c_value_t xor_reduce() const;
sc_logi c_value_t xnor _reduce() const;
// Common methods
int length() const;
// Expl icit conversions to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
bool is_01() const;
// Other methods
voi d pr int( std::ostream& os = std::cout ) const;
pri vate:
// Di sabl ed
sc_concr ef

();
sc_concr ef_r

< T1,T2>& oper ator = ( const sc_concr ef_r

< T1,T2>& );
} ;
// -------------------------------------------------------------
templ ate <class T1, class T2>
class sc_concr ef

: publi c sc_concr ef_r

<T1,T2>
{
publ ic:
// Copy constructor
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


288
Copyright 2012 IEEE. All rights reserved.
sc_concr ef

( const sc_concr ef

< T1,T2>& a );
// Assi gnment operators
templ ate <class T>
sc_concr ef

< T1,T2>& oper ator = ( const sc_subr ef_r

<T> & a );
templ ate <class T1, class T2>
sc_concr ef

< T1,T2>& oper ator = ( const sc_concr ef_r

< T1,T2>& a );
sc_concr ef

< T1,T2>& oper ator = ( const sc_bv_base& a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_lv_base& a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_concr ef

< T1,T2>& a );
sc_concr ef

< T1,T2>& oper ator = ( const char* a );


sc_concr ef

< T1,T2>& oper ator = ( const bool* a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_logic* a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_unsigned& a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_si gned& a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_ui nt_base& a );


sc_concr ef

< T1,T2>& oper ator = ( const sc_int_base& a );


sc_concr ef

< T1,T2>& oper ator = ( unsi gned long a );


sc_concr ef

< T1,T2>& oper ator = ( l ong a );


sc_concr ef

< T1,T2>& oper ator = ( unsi gned int a );


sc_concr ef

< T1,T2>& oper ator = ( i nt a );


sc_concr ef

< T1,T2>& oper ator = ( uint64 a );


sc_concr ef

< T1,T2>& oper ator = ( i nt64 a );


// Bitwise rotati ons
sc_concr ef

< T1,T2>& lr otate( i nt n );


sc_concr ef

< T1,T2>& r rotate( i nt n );


// Bitwise reverse
sc_concr ef

< T1,T2>& reverse();


// Bit selecti on
sc_bi tref

< sc_concr ef

<T1,T2> > oper ator [] ( i nt i );


// Part selection
sc_subr ef

< sc_concr ef

< T1,T2> > oper ator () ( i nt hi , int lo );


sc_subr ef

< sc_concr ef

< T1,T2> > r ange( i nt hi , int lo );


// Other methods
void scan( std::i stream& = std::cin );
pri vate:
// Di sabl ed
sc_concr ef

();
} ;
// r-val ue concatenation operators and functi ons
templ ate <typename C1, typename C2>
sc_concr ef_r

< C1,C2> oper ator, ( C1 , C2 );


templ ate <typename C1, typename C2>
sc_concr ef_r

< C1,C2> concat( C1 , C2 );


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


289
Copyright 2012 IEEE. All rights reserved.
// l-val ue concatenation operators and functi ons
templ ate <typename C1, typename C2>
sc_concr ef

< C1,C2> oper ator, ( C1 , C2 );


templ ate <typename C1, typename C2>
sc_concr ef

< C1,C2> concat( C1 , C2 );


} // namespace sc_dt
7.9.9.3 Constraints on usage
Concatenati on obj ects shal l only be created usi ng the concat function (or oper ator,) accordi ng to the rules
in 7.2.7. The concatenation arguments shall be objects wi th a common concatenation base type of
sc_bv_baseor sc_lv_base(or an instance of a class derived from sc_bv_base or sc_lv_base) or a part-sel ect
or concatenation of them.
An appl ication shall not expli citl y create an instance of any concatenation class.
An appl ication should not decl are a reference or pointer to any concatenati on object.
An rvalue concatenation shall be created when any argument to the concat functi on (or oper ator,) is an
rvalue. An rvalue concatenati on shal l not be used to modif y any vector wi th which it i s associated.
I t is strongl y recommended that an applicati on avoi d the use of a concatenati on as the return type of a
f uncti on because the lif eti me of the objects to which the concatenati on refer may not extend beyond the
f uncti on return statement.
Exampl e:
sc_dt::sc_concref_r<sc_bv_base,sc_bv_base> pad(sc_bv_base& bv, char pchar) {
const sc_bv<4> padword(pchar); // Unsaf e: returned concatenation references
// a non-static local variable (padword)
return concat(bv,padword);
}
7.9.9.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to lvalue concatenations. If the size of a data type or string literal operand di ff ers f rom
the concatenati on word length, truncation or zero-extension shall be used, as described i n 7.2.1. If an array
of bool or array of sc_logic is assigned to a concatenation and its number of elements is less than the
concatenation word length, the value of the concatenati on shal l be undef ined.
The def ault assignment operator for an rvalue concatenation shall be declared as pri vate to prevent i ts use by
an appli cati on.
7.9.9.5 Explicit type conversion
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


290
Copyright 2012 IEEE. All rights reserved.
const std::string to_str ing( sc_numrep , bool ) const;
Member function to_str ing shal l perform the conversion to an std::str ing representati on, as
descri bed in 7.2.11. Cal li ng the to_str ing f unction wi th a si ngl e argument i s equivalent to call ing the
to_str ing functi on wi th two arguments, where the second argument is true. Attempti ng to call the
single or double argument to_str ing function for a concatenation with one or more elements set to
the high-i mpedance or unknown state shall be an error.
Call ing the to_str ing function with no arguments shall create a logic val ue stri ng wi th a single '1',
'0' , 'Z ', or 'X ' corresponding to each bit. This string shall not pref ixed by " 0b" or a leadi ng zero.
bool is_01() const;
Member f unction is_01 shal l return true only when every element of a concatenati on has a value of
logi c 0 or logi c 1. If any el ement has the value hi gh-impedance or unknown, i t shal l return false.
Member f uncti ons that return the integer equi val ent of the bit representation shall be provided to
satisfy the requirements of 7.2.9. Call ing any such integer conversi on function f or an obj ect havi ng
one or more bi ts set to the hi gh-impedance or unknown state shal l be an error.
7.9.9.6 Bitwise and comparison operators
Operati ons speci fi ed in Table 29 and Tabl e 31 are permitted f or al l vector concatenations; operati ons
specif ied in Tabl e 30 are permitted for l val ue vector concatenations onl y. The foll owing appli es:
C represents an lvalue or rvalue vector concatenati on.
L represents an lvalue vector concatenation.
Vi represents an obj ect of logic vector type sc_bv_base, sc_lv_base, sc_subr ef_r

< T>, or
sc_concr ef_r

< T1,T2>, or i nteger type int, long, unsigned int, unsigned long, sc_signed,
sc_unsigned, sc_int_base, or sc_uint_base.
i represents an obj ect of integer type int.
A represents an array obj ect with el ements of type char , bool, or sc_logic.
The operands may al so be of any other cl ass that i s derived from those just given.
Binary bi twise operators shal l return a result wi th a word length that i s equal to the word length of the
longest operand.
The lef t shi ft operator shal l return a resul t with a word length that i s equal to the word l ength of its
concatenation operand plus the ri ght (i nteger) operand. Bi ts added on the ri ght-hand side of the resul t shal l
be set to zero.
The ri ght shi ft operator shal l return a resul t wi th a word length that i s equal to the word length of i ts
concatenation operand. Bits added on the lef t-hand side of the resul t shal l be set to zero.
sc_concr ef

< T1,T2> & lr otate( i nt n );


Member f uncti on lr otate shall rotate an lvalue part-select n places to the left.
sc_concr ef

< T1,T2> & r rotate( i nt n );


Member f uncti on r rotate shal l rotate an lvalue part-select n pl aces to the ri ght.
sc_concr ef

< T1,T2> & reverse();


Member f uncti on reverse shal l reverse the bit order in an lvalue part-select.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


291
Copyright 2012 IEEE. All rights reserved.
Table 29sc_concref_r

<T1,T2> bitwise operations


Expr ession Retur n type Oper ation
C & Vi const sc_l v_base sc_concr ef_r

< T1,T2> bi twi se and


Vi & C const sc_l v_base sc_concr ef_r

< T1,T2> bi twi se and


C & A const sc_l v_base sc_concr ef_r

< T1,T2> bi twi se and


A & C const sc_l v_base sc_concr ef_r

< T1,T2> bi twi se and


C | Vi const sc_l v_base sc_concr ef_r

< T1,T2> bi twi se or


Vi | C const sc_l v_base sc_concr ef_r < T1,T2> bi twi se or
C | A const sc_l v_base sc_concr ef_r < T1,T2> bi twi se or
A | C const sc_l v_base sc_concr ef_r < T1,T2> bi twi se or
C ^ Vi const sc_l v_base sc_concr ef_r < T1,T2> bi twi se excl usi ve or
Vi ^ C const sc_l v_base sc_concr ef_r < T1,T2>

bi twi se excl usi ve or
C ^ A const sc_l v_base sc_concr ef_r < T1,T2> bi twi se excl usi ve or
A ^ C const sc_l v_base sc_concr ef_r < T1,T2> bi twi se excl usi ve or
C << i const sc_l v_base sc_concr ef_r < T1,T2> l ef t-shi f t
C >> i const sc_l v_base sc_concr ef_r < T1,T2> ri ght-shi f t
~C const sc_l v_base sc_concr ef_r < T1,T2> bi twi se compl ement
Table 30sc_concref

<T1,T2> bitwise operations


Expr ession Retur n type Oper ation
L & = Vi sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assign bi twi se and


L & = A sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assi gn bi twi se and


L |= Vi sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assign bi twi se or


L |= A sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assi gn bi twi se or


L ^= Vi sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assi gn bitwi se excl usi ve or


L ^= A sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assign bi twi se excl usi ve or


L <<= i sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assign l ef t-shif t


L >>= i sc_concr ef

< T1,T2>& sc_concr ef

< T1,T2> assign ri ght-shi f t


IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


292
Copyright 2012 IEEE. All rights reserved.
NOTEAn implementation is required to supply overl oaded operators on sc_concr ef_r

< T1,T2> and


sc_concr ef

< T1,T2> obj ects to sati sf y the requi rements of thi s subcl ause. I t i s unspeci f ied whether these operators are
members of sc_concr ef_r

< T1,T2>, members of sc_concr ef

< T1,T2>, gl obal operators, or provi ded in someother way.


7.9.9.7 Other member functions
void scan( std::i stream& i s = std::ci n );
Member f uncti on scan shall set the val ues of the bits ref erenced by an lvalue concatenati on by
reading the next f ormatted character stri ng f rom the specif ied i nput stream (see 7.2.10).
void pr int( std::ostream& os = std::cout ) const;
Member f uncti on pr int shal l pri nt the val ues of the bits ref erenced by the concatenation to the
specif ied output stream (see 7.2.10).
int length() const;
Member f uncti on length shall return the word length of the concatenation (see 7.2.4).
7.9.9.8 Function concat and operator,
templ ate <typename C1, typename C2>
sc_concr ef_r

< C1,C2> oper ator, ( C1 , C2 );


templ ate <typename C1, typename C2>
sc_concr ef_r

< C1,C2> concat( C1 , C2 );


templ ate <typename C1, typename C2>
sc_concr ef

< C1,C2> oper ator, ( C1 , C2 );


templ ate <typename C1, typename C2>
sc_concr ef

< C1,C2> concat( C1 , C2 );


Expl ici t templ ate speciali zati ons of function concat and oper ator, shal l be provided for al l permitted
concatenations. Attempting to concatenate any two obj ects that do not have an expli ci t template
speciali zation for f unction concat or oper ator, def ined shall be an error.
A template speci al izati on for rvalue concatenations shal l be provi ded for all combinati ons of concatenation
argument types C1 and C2. Argument C1 has a type i n the f ol lowi ng l ist:
sc_bi tref_r

< T>
Table 31sc_concref_r

<T1,T2> comparison operations


Expr ession Retur n type Oper ation
C == Vi bool test equal
Vi == C bool test equal
C == A bool test equal
A == C bool test equal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


293
Copyright 2012 IEEE. All rights reserved.
sc_subr ef_r

< T>
sc_concr ef_r

< T1,T2>
const sc_bv_base&
const sc_l v_base&
Argument C2 has one of the types j ust gi ven or a type i n the f oll owing li st:
sc_bi tref

<T>
sc_subr ef

< T>
sc_concr ef

<T1,T2>
sc_bv_base&
sc_l v_base&
Additional templ ate special izations for rval ue concatenati ons shal l be provi ded f or the cases where a si ngl e
argument has type bool, const char * , or const sc_logic& . Thi s argument shal l be impl icitly converted to an
equi val ent si ngl e-bit const sc_lv_base obj ect.
A template speci ali zati on f or l val ue concatenations shall be provi ded for all combinati ons of concatenation
argument types C1 and C2, where each argument has a type in the foll owing li st:
sc_bi tref

<T>
sc_subr ef

< T>
sc_concr ef

<T1,T2>
sc_bv_base&
sc_l v_base&
7.10 Fixed-point types
This subclause descri bes the f ixed-point types and the operations and conventions imposed by these types.
7.10.1 Fixed-point representation
I n the SystemC binary fi xed-poi nt representation, a number shall be represented by a sequence of bits wi th a
specif ied positi on f or the bi nary point. Bi ts to the l eft of the binary point shal l represent the i nteger part of
the number, and bi ts to the ri ght of the bi nary poi nt shal l represent the f racti onal part of the number.
A SystemC fi xed-point type shal l be characterized by the fol lowing:
The word length (wl), whi ch shal l be the total number of bits i n the number representation.
The integer word length (iwl), whi ch shall be the number of bits in the integer part (the position of
the binary poi nt rel ative to the left-most bit).
The bit encoding (which shall be signed, twos compliment, or unsigned).
The ri ght-most bi t of the number shal l be the l east signif icant bi t (LSB), and the left-most bit shall be the
most signif icant bi t (MSB).
The bi nary poi nt may be located outside of the data bits. That is, the binary point may be a number of bit
posi ti ons to the ri ght of the LSB or it may be a number of bit positions to the l ef t of the MSB.
The f ixed-point representati on can be interpreted accordi ng to the f oll owing three cases:
wl < iwl
There are (iwl-wl) zeros between the LSB and the binary poi nt. See index 1 in Table 32 f or an
exampl e of this case.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


294
Copyright 2012 IEEE. All rights reserved.
0 <= iwl <= wl
Thebinary poi nt is contained withi n the bit representati on. See index 2, 3, 4, and 5 i n Table32 for
exampl es of thi scase.
iwl < 0
Thereare(-iwl) si gn-extended bitsbetween thebinary poi nt and theMSB. For an unsigned type, the
sign-extended bi ts arezero. For asi gned type, theextended bits repeat theMSB. See index 6 and 7
in Table32 for exampl esof thi scase.
TheMSB in thefixed-point representati onof asignedtypeshall bethesign bit. Thesign bit may bebehi nd
thebinary poi nt.
Therangeof val ues for asigned fixed-poi nt format shal l begi ven by thefoll owing:
Therangeof val ues for aunsi gned fi xed-point format shall begivenby thefoll owing:
7.10.2 Fixed-point type conversion
Fixed-point type conversi on (conversion of a value to a specific fixed-poi nt representation) shall be
performed whenever aval uei sassigned to afixed-point typevariable(i ncl udi ngi niti ali zati on).
Table 32Examples of fixed-point formats
I ndex wl iwl Fixed-point
r epr esentation
a
a
x isan arbitrary binary digit, 0, or 1. s isasi gn-extended digit, 0, or 1.
Range signed Ranged unsigned
1 5 7 xxxxx00. [64,60] [0,124]
2 5 5 xxxxx. [16,15] [0,31]
3 5 3 xxx.xx [4,3.75] [0,7.75]
4 5 1 x.xxxx [1,0.9375] [0,1.9375]
5 5 0 .xxxxx [0.5,0.46875] [0,0.96875]
6 5 2 .ssxxxxx [0.125,0.1171875] [0,0.2421875]
7 1 1 .sx [0.25,0] [0,0.25]
2
i wl 1
f 2
i wl 1
2
wl i wl
[ , ]
0 2
i wl
2
wl i wl
[ , ]
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


295
Copyright 2012 IEEE. All rights reserved.
I f the magnitude of the val ue i s outsi de the range of the fi xed-poi nt representation, or the val ue has greater
precision than the fi xed-poi nt representati on provides, it shal l be mapped (converted) to a value that can be
represented. This conversion shall be performed i n two steps:
a) I f the val ue is wi thin range but has greater preci si on (i t i s between representable values),
quantization shall be perf ormed to reduce the preci si on.
b) I f the magnitude of the val ue i s outsi de the range, overfl ow handli ng shall be performed to reduce
the magni tude.
I f the target fi xed-poi nt representati on has greater preci si on, the additional least si gni fi cant bits shal l be zero
extended. I f the target fixed-point representation has a greater range, si gn extensi on or zero extensi on shall
be performed f or signed and unsi gned fi xed-poi nt types, respecti vely, to extend the representation of their
most signif icant bi ts.
Mul ti pl e quanti zation modes (di stinct quanti zation characteristi cs) and mul tipl e overf low modes (distinct
overfl ow characteri stics) are def ined (see 7.10.9.1 and 7.10.9.9).
7.10.3 Fixed-point data types
This subclause descri bes the cl asses that are provi ded to represent fi xed-poi nt val ues.
7.10.3.1 Finite-precision fixed-point types
The f ollowi ng f ini te- and vari abl e-precision fi xed-point data types shal l be provided:
sc_f ixed<wl ,iwl ,q_mode,o_mode,n_bi ts>
sc_ufi xed<wl ,iwl ,q_mode,o_mode,n_bits>
sc_f ix
sc_ufi x
sc_f xval
These types shall be parameteri zed as to the f ixed-point representati on (wl, iwl) and f ixed-point conversion
modes (q_mode, o_mode, n_bits). The declaration of a vari abl e of one of these types shal l speci fy the
val ues f or these parameters. The type parameter val ues of a vari abl e shall not be modi fi ed af ter the variable
decl arati on. Any data val ue assigned to the variabl e shal l be converted to speci fi ed representation (with the
specif ied word length and binary poi nt location) wi th the specif ied quantizati on and overf low processing
(q_mode, o_mode, n_bits) appli ed if requi red.
The f ini te-precisi on f ixed-poi nt types have a common base cl ass sc_fxnum. An appl ication or
impl ementation shal l not directly create an obj ect of type sc_fxnum. A ref erence or poi nter to class
sc_fxnum may be used to access an object of any type derived from sc_fxnum.
The type sc_fxval i s a variable-preci si on type. A vari abl e of type sc_fxval may store a f ixed-poi nt val ue of
arbitrary wi dth and bi nary point l ocation. A value assi gned to a sc_fxval variable shall be stored wi thout a
loss of preci si on or magnitude (the value shall not be modif ied by quantization or overfl ow handli ng).
Types sc_fixed, sc_fix, and sc_fxval shall have a signed (twos compli ment) representati on. Types
sc_ufixed and sc_ufix have an unsi gned representation.
A fixed-point variable that i s declared without an initial val ue shall be uninitiali zed. Uni ni ti alized vari ables
may be used wherever the use of an initiali zed vari able i s permitted. The result of an operation on an
uninitiali zed variable shal l be undef ined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


296
Copyright 2012 IEEE. All rights reserved.
7.10.3.2 Limited-precision fixed-point types
The f ol lowi ng l imi ted-preci si on versions of the f ixed-point types shall be provided:
sc_f ixed_f ast<wl ,iwl,q_mode,o_mode,n_bi ts>
sc_ufi xed_fast<wl ,iwl ,q_mode,o_mode,n_bi ts>
sc_f ix_fast
sc_ufi x_fast
sc_f xval_f ast
The l imited-preci si on types shall use the same semanti cs as the fi nite-preci sion fixed-point types. Finite-
precision and l imi ted-precision types may be mixed f reel y i n expressions. A vari able of a limited-preci si on
type shal l be a legal repl acement i n any expressi on where a vari abl e of the correspondi ng fi nite-preci sion
f ixed-poi nt type i s expected.
The l imi ted-precisi on fi xed-poi nt val ue shal l be held in an impl ementation-dependent native C++ f loati ng-
point type. An impl ementation shall provi de a mini mum l ength of 53 bi ts to represent the mantissa.
NOTEFor bit-true behavior with the l i mited-preci si on types, the word l ength of the resul t of any operati on or
expressi on shoul d not exceed 53 bi ts.
7.10.4 Fixed-point expressions and operations
Fixed-point operations shal l be perf ormed using variable-precisi on fi xed-poi nt values; that is, the eval uati on
of a fi xed-poi nt operator shal l proceed as f ol lows (except as noted below for speci fi c operators):
The operands shall be converted (promoted) to vari able-preci si on f ixed-point values.
The operation shall be performed, computing a variabl e-precision fi xed-poi nt result. The result shall
be computed so that there is no l oss of precision or magnitude (that i s, suf fi cient bi ts are computed to
precisel y represent the result).
The ri ght-hand si de of a fi xed-poi nt assi gnment shall be eval uated as a vari abl e-precision f ixed-point val ue
that i s converted to the f ixed-point representation speci fi ed by the target of the assi gnment.
I f al l the operands of a fi xed-poi nt operation are li mited-preci si on types, a l imited-preci si on operation shal l
be perf ormed. Thi s operation shall use limited vari able-preci si on f ixed-point values (sc_fxval_fast), and the
result shall be a l imited variable-precision f ixed-poi nt value.
The right operand of a fixed-point shif t operation (the shif t amount) shall be of type int. I f a f ixed-point shif t
operation is call ed with a fi xed-poi nt val ue for the ri ght operand, the fractional part of the value shall be
truncated (no quanti zation).
The result of the equali ty and rel ational operators shall be type bool.
Fixed-point operands of a bi twi se operator shall be of a fi nite- or l imited-preci sion type (they shall not be
variable precision). Furthermore, both operands of a bi nary bi twi se operator shal l have the same si gn
representation (both si gned or both unsigned). The resul t of a f ixed-poi nt bi twi se operati on shal l be either
sc_fix or sc_ufix (or sc_fix_fast or sc_ufix_fast), depending on the si gn representation of the operands. For
binary operators, the two operands shal l be ali gned at the bi nary poi nt. The operands shall be temporaril y
extended (if necessary) to have the same integer word length and fracti onal word l ength. The resul t shall
have the same integer and f racti onal word lengths as the temporari ly extended operands.
The remai nder operator (%) is not supported f or fi xed-poi nt types.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


297
Copyright 2012 IEEE. All rights reserved.
The permitted operators are given i n Table 33. The foll owing appl ies:
A represents a fi xed-poi nt obj ect.
B and C represent appropriate numeri c values or obj ects.
s1, s2, s3 represent si gned f ini te- or l imi ted-precision fi xed-poi nt objects.
u1, u2, u3 represent unsigned f inite- or l imited-precision f ixed-point obj ects.
The operands of arithmeti c f ixed-point operati ons may be combinations of the types li sted i n Table 34,
Tabl e 35, Tabl e 36, and Tabl e 37.
The addition operations specif ied in Table 34 are permi tted f or fi nite-precision fi xed-poi nt obj ects. The
f ol lowi ng appl ies:
F, F1, F2 represent obj ects derived from type sc_fxnum.
n represents an obj ect of numeric type int, long, unsigned int, unsigned long, float, double,
sc_signed, sc_unsigned, sc_int_base, sc_uint_base, sc_fxval, or sc_fxval_fast, or an obj ect
derived from sc_fxnum_fast or a numeric stri ng l iteral.
The operands may al so be of any other cl ass that i s derived from those just given.
Table 33Fixed-point arithmetic and bitwise functions
Expr ession Oper ation
A = B + C; Addi ti on wi th assi gnment
A = B - C; Subtracti on wi th assi gnment
A = B * C; Mul ti pl i cati on wi th assi gnment
A = B / C; Di vi si on wi th assi gnment
A = B << i ; Left shi f t wi th assi gnment
A = B >> i ; Ri ght shi f t wi th assi gnment
s1 = s2 & s3; Bi twi se and wi th assi gnment f or si gned operands
s1 = s2 | s3; Bi twi se or wi th assi gnment f or si gned operands
s1 = s2 ^ s3; Bi twi se excl usi ve-or wi th assi gnment f or si gned operands
u1 = u2 & u3; Bi twi se and wi th assi gnment for unsi gned operands
u1 = u2 | u3; Bi twi se or wi th assi gnment f or unsi gned operands
u1 = u2 ^ u3; Bi twi se excl usi ve-or wi th assi gnment f or unsi gned operands
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


298
Copyright 2012 IEEE. All rights reserved.
The addition operations specif ied in Table 35 are permitted for variable-preci si on fixed-point obj ects. The
f ol lowi ng appl ies:
V , V1, V2 represent obj ects of type sc_fxval.
n represents an obj ect of numeric type int, long, unsigned int, unsigned long, float, double,
sc_signed, sc_unsigned, sc_int_base, sc_uint_base, or sc_fxval_fast, or an obj ect deri ved from
sc_fxnum_fast or a numeric stri ng l iteral.
The operands may al so be of any other cl ass that i s derived from those just given.
The addi ti on operati ons speci fi ed in Table 36 are permitted for l imi ted-preci si on fi xed-poi nt obj ects. The
f ol lowi ng appl ies:
F, F1, F2 represent obj ects derived from type sc_fxnum_fast.
n represents an obj ect of numeric type int, long, unsigned int, unsigned long, float, double,
sc_signed, sc_unsigned, sc_int_base, sc_uint_base, or sc_fxval_fast, or a numeric stri ng l iteral.
The operands may al so be of any other cl ass that i s derived from those just given.
The addition operati ons specif ied in Table 37 are permi tted f or li mited vari abl e-precision fi xed-poi nt
objects. The fol lowing appl ies:
V , V1, V2 represent obj ects of type sc_fxval_fast.
Table 34Finite-precision fixed-point addition operations
Expr ession Oper ation
F = F1 + F2; sc_fxnum additi on, sc_f xnum assi gn
F1 += F2; sc_fxnum assign addi ti on
F1 = F2 + n; sc_f xnum addi ti on, sc_f xnum assi gn
F1 = n + F2; sc_fxnum additi on, sc_f xnum assi gn
F += n; sc_fxnum assign addi ti on
Table 35Variable-precision fixed-point addition operations
Expr ession Oper ation
V = V1 + V2; sc_f xval additi on,
sc_f xval assi gn
V1 += V2; sc_f xval assign addi ti on
V1 = V2 + n; sc_f xval addi ti on,
sc_f xval assi gn
V1 = n + V2; sc_f xval addi ti on,
sc_f xval assi gn
V += n; sc_f xval assi gn addi ti on
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


299
Copyright 2012 IEEE. All rights reserved.
n represents an obj ect of numeric type int, long, unsigned int, unsigned long, float, double,
sc_signed, sc_unsigned, sc_int_base, or sc_uint_base, or a numeric stri ng l iteral .
The operands may al so be of any other cl ass that i s derived from those just given.
Subtracti on, multipli cati on, and di vi si on operations are al so permitted wi th the same combinati ons of
operand types as l isted in Tabl e 34, Tabl e 35, Tabl e 36, and Tabl e 37.
7.10.5 Bit and part selection
Bit and part selection shall be supported for the f ixed-poi nt types, as described in 7.2.5 and 7.2.6. They are
not supported f or the variable-precision fi xed-poi nt types sc_fxval or sc_fxval_fast.
I f the l eft-hand i ndex of a part-sel ect is less than the ri ght-hand i ndex, the bit order of the part-select shall be
reversed.
A part-sel ect may be created with an unspecif ied range (the r ange function or oper ator () is call ed with no
arguments). In this case, the part-select shall have the same word length and same val ue as its associ ated
f ixed-poi nt object.
Table 36Limited-precision fixed-point addition operations
Expr ession Oper ation
F = F1 + F2; sc_f xnum_f ast addi ti on,
sc_fxnum_f ast assi gn
F1 += F2; sc_f xnum_f ast assi gn addi ti on
F1 = F2 + n; sc_fxnum_f ast addi ti on,
sc_fxnum_f ast assi gn
F1 = n + F2; sc_f xnum_f ast addi ti on,
sc_fxnum_f ast assi gn
F += n; sc_fxnum_f ast assi gn addi ti on
Table 37Limited variable-precision fixed-point addition operations
Expr ession Oper ation
V = V1 + V2; sc_f xval _f ast addi ti on,
sc_fxval _fast assi gn
V1 += V2; sc_f xval _f ast assi gn addi ti on
V1 = V2 + n; sc_fxval _f ast addi ti on,
sc_fxval _fast assi gn
V1 = n + V2; sc_f xval _f ast additi on,
sc_fxval _fast assi gn
V += n; sc_fxval _f ast assi gn addi ti on
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


300
Copyright 2012 IEEE. All rights reserved.
7.10.6 Variable-precision fixed-point value limits
I n some cases, such as divi si on, usi ng variable precision could l ead to i nf ini te word lengths. An
implementation shoul d provi de an appropriate mechani sm to def i ne the maximum permitted word l ength of
a variabl e-precision value and to detect when this maxi mum word length is reached.
The action taken by an i mplementati on when a variable-preci si on value reaches its maximum word l ength i s
undef ined. The result of any operation that causes a vari able-preci sion val ue to reach i ts maxi mum word
length shal l be the i mpl ementation-dependent representable value nearest to the ideal (i nfi ni te precision)
result.
7.10.7 Fixed-point word length and mode
The def aul t word length, quantization mode, and saturation mode of a fi xed-point type shal l be set by the
f ixed-poi nt type parameter (sc_fxtype_param) in context at the poi nt of construction as descri bed i n 7.2.3.
The fi xed-point type parameter shall have a f ield correspondi ng to the f ixed-point representation (wl,.iwl)
and fi xed-poi nt conversion modes (q_mode, o_mode, n_bits). Def ault val ues f or these fi el ds shall be
def ined according to Tabl e 38.
The behavior of a fi xed-poi nt obj ect i n arithmetic operations may be set to emul ate that of a fl oating-point
variable by the fl oati ng-poi nt cast swi tch i n context at its poi nt of construction. A f loating-poi nt cast swi tch
shall be brought into context by creating a fl oati ng-poi nt cast context object. sc_fxcast_switch and
sc_fxcast_context shall be used to create fl oating-point cast switches and f l oati ng-poi nt cast contexts,
respecti vel y (see 7.11.5 and 7.11.6).
A gl obal f loating-poi nt cast context stack shall manage fl oating-point cast contexts using the same semantics
as the length context stack described in 7.2.3.
A f loati ng-poi nt cast swi tch may be initiali zed to the value SC_ON or SC_OFF. These shal l cause the
ari thmeti c behavior to be fi xed-poi nt or floati ng-poi nt, respecti vel y. A def aul t f loati ng-poi nt context wi th
the val ue SC_ON shal l be defi ned.
Exampl e:
sc_fxtype_params f xt(32,16);
sc_f xtype_context fcxt(fxt);
sc_f ix A,B,res; // wl = 32, iwl = 16
Table 38Built-in default values
Parameter Value
wl 32
i wl 32
q_mode SC_TRN
o_mode SC_WRAP
n_bi ts 0
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


301
Copyright 2012 IEEE. All rights reserved.
A = 10.0;
B = 0.1;
res = A * B; // res = .999908447265625
sc_f xcast_swi tch fxs(SC_OFF);
sc_f xcast_context f ccxt(fxs);
sc_f ix C,D; // Floating-poi nt behavior
C = 10.0;
D = 0.1;
res = C * D; // res = 1
7.10.7.1 Reading parameter settings
The f ol lowi ng functions are def ined for every f ini te-preci si on f ixed-poi nt obj ect and li mi ted-precision f ixed-
point object and shal l return its current parameter settings (at runtime).
const sc_f xcast_switch& cast_switch() const;
Member f uncti on cast_switch shal l return the cast switch parameter.
int iwl() const;
Member f uncti on iwl shal l return the i nteger word-l ength parameter.
int n_bits() const;
Member f uncti on n_bitsshall return the number of saturated bits parameter.
sc_o_mode o_mode() const;
Member f uncti on o_mode shal l return the overflow mode parameter usi ng the enumerated type
sc_o_mode, def ined as foll ows:
enum sc_o_mode
{
SC_SAT, // Saturation
SC_SAT_ZERO, // Saturation to zero
SC_SAT_SYM, // Symmetri cal saturation
SC_WRAP, // Wrap-around (* )
SC_WRAP_SM // Si gn magnitude wrap-around (* )
} ;
sc_q_mode q_mode() const;
Member functi on q_mode shall return the quantizati on mode parameter usi ng the enumerated type
sc_q_mode, def ined as foll ows:
enum sc_q_mode
{
SC_RND, // Rounding to plus infi nity
SC_RND_ZERO, // Rounding to zero
SC_RND_MI N_INF, // Rounding to minus i nfi nity
SC_RND_INF, // Rounding to inf inity
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


302
Copyright 2012 IEEE. All rights reserved.
SC_RND_CONV, // Convergent rounding
SC_TRN, // Truncation
SC_TRN_ZERO // Truncati on to zero
} ;
const sc_f xtype_params& type_par ams() const;
Member f uncti on type_par ams shall return the type parameters.
int wl() const;
Member f uncti on wl shall return the total word-length parameter.
7.10.7.2 Value attributes
The f ol lowi ng f unctions are def ined for every fi xed-poi nt object and shall return its current val ue attri butes.
bool is_neg() const;
Member function is_neg shall return true i f the object holds a negative val ue; otherwise, the return
val ue shal l be false.
bool is_zer o() const;
Member f unction is_zer o shal l return true i f the object hol ds a zero value; otherwise, the return
val ue shal l be false.
bool over flow_flag() const;
Member f unction over flow_flag shall return true if the last write action on this obj ects caused
overfl ow; otherwi se, the return value shall be false.
bool quantization_flag() const;
Member f unction quantization_flag shal l return true i f the l ast wri te action on thi s obj ect caused
quantization; otherwise, the return val ue shal l be false.
The f ollowi ng f unction i s defi ned for every f inite-preci sion f i xed-point object and shal l return its current
val ue:
const sc_f xval value() const;
The f ollowi ng f uncti on i s defi ned for every li mi ted-precisi on f ixed-point object and shal l return its current
val ue:
const sc_f xval_f ast value() const;
7.10.8 Conversions to character string
Conversi on to character string of the f ixed-poi nt types shal l be supported by the to_str ing method, as
descri bed in 7.3.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


303
Copyright 2012 IEEE. All rights reserved.
The to_str ing method for fi xed-point types may be cal led wi th an addi ti onal argument to specif y the string
f ormat. Thi s argument shall be of enumerated type sc_fmt and shal l al ways be at the ri ght-hand si de of the
argument li st.
enum sc_fmt { SC_F, SC_E } ;
The default value for fmt shall be SC_F f or the fi ni te- and l imi ted-preci si on f ixed-poi nt types. For types
sc_fxval and sc_fxval_fast, the def aul t value f or fmt shall be SC_E.
The sel ected format shall give di ff erent character stri ngs onl y when the binary poi nt is not located wi thin the
wl bits. In that case, ei ther si gn extensi on (MSB si de) or zero extension (LSB si de) shal l be done (SC_F
f ormat), or exponents shal l be used (SC_E f ormat).
I n conversion to SC_DEC number representati on or conversion from a variable-preci si on variable, onl y
those characters necessary to represent the val ue uni quely shall be generated. In converting the value of a
f inite- or li mi ted-precision variable to a binary, octal, or hex representation, the number of characters used
shal l be determined by the i nteger and fractional wi dths (iwl , fwl) of the variable (with sign or zero
extension as needed).
Exampl e:
sc_fixed<7,4> a = 1.5;
a.to_stri ng(SC_DEC); // 1.5
a.to_stri ng(SC_BI N); // 0b1110.100
sc_fxval b = 1.5;
b.to_stri ng(SC_BIN); // 0b10.1
sc_f ixed<4,6> c = 20;
c.to_stri ng(SC_BIN,f al se,SC_F); // 010100
c.to_stri ng(SC_BIN,f al se,SC_E); // 0101e+2
7.10.8.1 String shortcut methods
Four shortcut methods to the to_str ing method shal l be provided f or f requently used combinati ons of
arguments. The shortcut methods are li sted i n Table 39.
The shortcut methods shall use the default stri ng f ormatting.
Table 39Shortcut methods
Shor tcut method Number r epr esentation
to_dec() SC_DEC
to_bi n() SC_BI N
to_oct() SC_OCT
to_hex() SC_HEX
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


304
Copyright 2012 IEEE. All rights reserved.
Exampl e:
sc_fixed<4,2> a = 1;
a.to_dec(); // Returnsstd::string wi th val ue"-1"
a.to_bi n(); // Returnsstd::string with val ue"0b11.00"
7.10.8.2 Bit-pattern string conversion
Bit-pattern strings may beassi gned to fi xed-poi nt part-selects. Theresul t of assi gning abi t-pattern string to
afi xed-point object (except using apart-select) i sundefi ned.
If thenumber of charactersin thebi t-pattern stri ngis lessthan thepart-sel ect word length, thestring shal l be
zero extendedat i tsleft-handsideto thepart-sel ect word length.
7.10.9 Finite word-length effects
Thefollowi ngsubcl ausesdescri betheoverfl ow and quanti zation modes of SystemC.
7.10.9.1 Overflow modes
Overflow shall occur when themagni tudeof aval uebei ng assigned to al imi ted-precision vari abl eexceeds
the fixed-point representation. In SystemC, specific overfl ow modes shall be avai lable to control the
mapping to arepresentabl evalue.
The mutual ly exclusive overflow modes li sted in Tabl e40 shall be provided. The default overflow mode
shall beSC_WRAP. When using awrap-around overfl ow mode, thenumber of saturated bits (n_bits) shal l
by default beset to 0 but can bemodified.
Inthefoll owing subcl auses, each overflow modeis explained in moredetai l. A fi gureisgi ven to explain the
behavior graphicall y. The x axi s shows the input values, and the y axis represents the output val ues.
Together they determinetheoverflow mode.
To facil itatetheexpl anati on of each overfl ow mode, theconcepts MIN andMAX areused:
In the case of signed representation, MIN is the lowest (negative) number that may berepresented;
MAX i sthehi ghest (positive) number that may berepresented with acertain number of bits. A val ue
x shall li ei n therange:

2
n1
(= MI N) <= x <= (2
n1
1) (= MAX)
Table 40Overflow modes
Overflow mode Name
Saturation SC_SAT
Saturationtozero SC_SAT_ZERO
Symmetrical saturation SC_SAT_SYM
Wrap-around
a
a
With 0 or n_bitssaturated bits(n_bits> 0). The default valuefor n_bits
is0.
SC_WRAP
Signmagnitudewrap-around
a
SC_WRAP_SM
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


305
Copyright 2012 IEEE. All rights reserved.
where n indicates the number of bi ts.
In the case of unsigned representation, MIN shall equal 0 and MAX shall equal 2
n
1, where n
indi cates the number of bi ts.
7.10.9.2 Overflow for signed fixed-point numbers
The f oll owing template contains a signed f ixed-poi nt number before and after an overf low mode has been
appl ied and a number of f lags. The fl ags are explained bel ow the template. The fl ags between parentheses
indicate the additional opti onal properties of a bit.
The f ollowi ng f lags and symbols are used i n the template just given and in Tabl e 41:
x represents a bi nary di git (0 or 1).
sD represents a si gn bi t bef ore overfl ow handl ing.
D represents deleted bits.
l D represents the l east signif icant del eted bit.
sR represents the bit on the MSB posi ti on of the resul t number. For the SC_WRAP_SM, 0 and
SC_WRAP_SM, 1 modes, a disti nction i s made between the ori ginal value (sRo) and the new val ue
(sRn) of this bit.
N represents the saturated bi ts. Their number is equal to the n_bi ts argument mi nus 1. They are
always taken after the sign bi t of the result number. The n_bi ts argument i s onl y taken i nto account
f or the SC_WRAP and SC_WRAP_SM overf low modes.
l N represents the l east si gni fi cant saturated bi t. Thi s fl ag i s onl y rel evant f or the SC_WRAP and
SC_WRAP_SM overf low modes. For the other overf low modes, these bits are treated as R-bits. For
the SC_WRAP_SM, n_bi ts > 1 mode, l No represents the ori ginal val ue of this bi t.
R represents the remaini ng bits.
l R represents the least si gni fi cant remaining bit.
Overf low shall occur when the value of at least one of the del eted bits (sD, D, l D) i s not equal to the origi nal
val ue of the bi t on the MSB position of the resul t (sRo).
Tabl e 41 shows how a signed fi xed-point number shall be cast (in case there is an overfl ow) f or each of the
possibl e overfl ow modes. The operators used i n the table are ! for a bitwise negation and ^ for a bitwise
excl usi ve-OR.
x x x x x x x x x x x x x x
x x x x x x x x x x
sD D D D l D sR R(N) R(IN) R R R R R R R R l R
x x x
x x
Before
After:
Flags:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


306
Copyright 2012 IEEE. All rights reserved.
Table 41Overflow handling for signed fixed-point numbers
Over flow mode Result
Sign bit (sR) Satur ated bits (N, lN) Remaining bits (R, lR)
SC_SAT sD ! sD
Theresul t number gets the si gn bi t of the ori gi nal number. Theremai ni ng bi tsshal l get
the i nverse val ue of the si gn bi t.
SC_SAT_ZERO 0 0
Al l bi ts shal l be set to zero.
SC_SAT_SYM sD ! sD,
Theresult number shal l get thesi gn bi t of the ori gi nal number. Theremai ni ng bi ts shal l
get the i nverse val ue of the si gn bi t, except the l east si gni f i cant remai ni ng bi t, whi ch
shall be set to one.
SC_WRAP, (n_bi ts =) 0 sR x
Al l bi ts except f or the del eted bi ts shal l be copi ed to the resul t.
SC_WRAP, (n_bi ts =) 1 sD x
Theresult number shal l get thesi gn bi t of the ori gi nal number. Theremai ni ng bi ts shal l
be copied from the ori gi nal number.
SC_WRAP, n_bits > 1 sD ! sD x
The resul t number shall get the si gn bit of the ori gi nal number. The saturated bi ts shal l
get the i nverse val ue of the sign bi t of the origi nal number. The remai ni ng bi ts shal l be
copi ed f rom the ori gi nal number.
SC_WRAP_SM,
(n_bi ts =) 0
l D x ^ sRo ^ sRn
The sign bi t of the resul t number shal l get the value of the least si gni fi cant del eted bi t.
The remai ni ng bi ts shal l be XORed wi th the ori gi nal and the new val ue of the si gn bi t
of the resul t.
SC_WRAP_SM,
(n_bi ts =) 1
sD x ^ sRo ^ sRn
Theresult number shal l get thesi gn bi t of the ori gi nal number. Theremai ni ng bi ts shal l
be XORed wi th the ori gi nal and the new val ue of the sign bi t of the resul t.
SC_WRAP_SM,
n_bi ts > 1
sD ! sD x ^I No ^ ! sD
The resul t number shall get the si gn bit of the ori gi nal number. The saturated bi ts shal l
get the i nverse val ue of the sign bi t of the origi nal number. The remai ni ng bi ts shal l be
XORed wi th the ori ginal val ue of the l east si gni f i cant saturated bi t and the i nverse
val ue of the ori gi nal si gn bi t.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


307
Copyright 2012 IEEE. All rights reserved.
7.10.9.3 Overflow for unsigned fixed-point numbers
The f oll owi ng template contai ns an unsi gned fi xed-point number bef ore and after an overf low mode has
been appl ied and a number of f lags. The f lags are expl ai ned below the template.
The f ollowi ng f lags and symbols are used i n the template just given and in Tabl e 42:
x represents an bi nary di gi t (0 or 1).
D represents deleted bits.
l D represents the l east signif icant del eted bit.
N represents the saturated bi ts. Thei r number is equal to the n_bi ts argument. The n_bi ts argument is
only taken i nto account f or the SC_WRAP and SC_WRAP_SM overf l ow modes.
R represents the remaini ng bits.
Tabl e 42 shows how an unsi gned fi xed-point number shal l be cast in case there i s an overfl ow f or each of
the possible overfl ow modes.
Table 42Overflow handling for unsigned fixed-point numbers
Over flow mode Result
Satur ated bits ( N) Remaining bits (R)
SC_SAT 1 (overf l ow) 0 (underf l ow)
The remai ni ng bits shal l be set to 1 (overf l ow) or 0 (underf l ow).
SC_SAT_ZERO 0
The remai ni ng bits shal l be set to 0.
SC_SAT_SYM 1 (overf low) 0 (underf l ow)
The remai ni ng bits shal l be set to 1 (overf l ow) or 0 (underf l ow).
SC_WRAP, (n_bi ts =) 0 x
Al l bi ts except f or the del eted bi ts shal l be copi ed to the resul t
number.
SC_WRAP, n_bi ts > 0 1 x
The saturated bits of the resul t number shal l be set to 1. The
remai ni ng bi ts shal l be copi ed to the resul t.
SC_WRAP_SM Not def i ned f or unsi gned numbers.
x x x x x x x x x x x x x x
x x x x x x x x x x
D D D D l D R(N) R(N) R(I N) R R R R R R R R R
x x x
x x
Before
After:
Flags:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


308
Copyright 2012 IEEE. All rights reserved.
Duri ng the conversi on f rom signed to unsi gned, sign extensi on shall occur bef ore overfl ow handl ing, whi le
in the unsi gned to si gned conversion, zero extensi on shal l occur f i rst.
7.10.9.4 SC_SAT
The SC_SAT overf low mode shall be used to i ndi cate that the output i s saturated to MAX in case of
overfl ow, or to MI N in the case of negati ve overf low. Figure 2 i ll ustrates the SC_SAT overfl ow mode for a
word l ength of three bits. The x axi s represents the word l ength bef ore roundi ng; the y axi s represents the
word l ength after rounding. The ideal si tuati on i s represented by the di agonal dashed l ine.
Figure 2Saturation for signed numbers
Exampl es (si gned, 3-bit number):
bef ore saturati on: 0110 (6)
after saturation: 011 (3)
There is an overfl ow because the deci mal number 6 is outsi de the range of val ues that can be
represented exactly by means of three bi ts. The resul t is then rounded to the hi ghest positive
representabl e number, which is 3.
bef ore saturati on: 1011 (5)
after saturation: 100 (4)
There is an overf low because the decimal number 5 is outside the range of values that can be
represented exactl y by means of three bits. The result i s then rounded to the lowest negative
representable number, which is 4.
Exampl e (unsi gned, 3-bit number):
bef ore saturati on: 01110 (14)
after saturation: 111 (7)
The SC_SAT mode corresponds to the SC_WRAP and SC_WRAP_SM modes with the
number of bits to be saturated equal to the number of kept bits.
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


309
Copyright 2012 IEEE. All rights reserved.
7.10.9.5 SC_SAT_ZERO
The SC_SAT_ZERO overfl ow mode shal l be used to i ndi cate that the output i s forced to zero in case of an
overfl ow, that i s, i f MAX or MI N is exceeded. Fi gure 3 i ll ustrates the SC_SAT_ZERO overf low mode for a
word l ength of three bits. The x axi s represents the word l ength bef ore roundi ng; the y axi s represents the
word l ength after rounding.
Figure 3Saturation to zero for signed numbers
Exampl es (si gned, 3-bit number):
bef ore saturation to zero: 0110 (6)
after saturation to zero: 000 (0)
There is an overfl ow because the deci mal number 6 is outsi de the range of val ues that can be
represented exactl y by means of three bits. The result is saturated to zero.
bef ore saturation to zero: 1011 (5)
after saturation to zero: 000 (0)
There is an overf low because the decimal number 5 is outside the range of values that can be
represented exactly by means of three bits. The result is saturated to zero.
Exampl e (unsi gned, 3-bit number):
bef ore saturation to zero: 01110 (14)
after saturation to zero: 000 (0)
7.10.9.6 SC_SAT_SYM
The SC_SAT_SYM overf low mode shal l be used to indicate that the output i s saturated to MAX i n case of
overflow, to MAX (signed) or MIN (unsigned) in the case of negati ve overfl ow. Fi gure 4 il lustrates the
SC_SAT_SYM overfl ow mode f or a word l ength of three bi ts. The x axi s represents the word l ength before
rounding; the y axis represents the word length after rounding. The ideal situation i s represented by the
diagonal dashed li ne.
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


310
Copyright 2012 IEEE. All rights reserved.
Figure 4Symmetrical saturation for signed numbers
Exampl es (si gned, 3-bit number):
after symmetri cal saturation: 0110 (6)
after symmetri cal saturation: 011 (3)
There is an overfl ow because the deci mal number 6 is outsi de the range of val ues that can be
represented exactly by means of three bi ts. The resul t is then rounded to the hi ghest positive
representabl e number, which is 3.
after symmetri cal saturation: 1011 (5)
after symmetri cal saturation: 101 (3)
There is an overf low because the decimal number 5 is outside the range of values that can be
represented exactly by means of three bits. The resul t is then rounded to minus the hi ghest
positive representable number, which is 3.
Exampl e (unsi gned, 3-bit number):
after symmetri cal saturation: 01110 (14)
after symmetri cal saturation: 111 (7)
7.10.9.7 SC_WRAP
The SC_WRAP overf low mode shall be used to indicate that the output is wrapped around i n the case of
overfl ow.
Two dif ferent cases are possibl e:
SC_WRAP with parameter n_bi ts = 0
SC_WRAP with parameter n_bi ts > 0
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


311
Copyright 2012 IEEE. All rights reserved.
SC_WRAP, 0
This shall be the defaul t overf low mode. All bi ts except for the del eted bits shall be copi ed to the result
number. Figure 5 i ll ustrates the SC_WRAP overf low mode for a word length of three bits with the n_bi ts
parameter set to 0. The x axis represents the word length before rounding; the y axi s represents the word
length after roundi ng.
Figure 5Wrap-around with n_bits = 0 for signed numbers
Exampl es (si gned, 3-bit number):
bef ore wrapping around with 0 bi ts: 0100 (4)
after wrapping around wi th 0 bi ts: 100 (4)
There is an overfl ow because the deci mal number 4 is outsi de the range of val ues that can be
represented exactly by means of three bits. The MSB is truncated, and the result becomes
negative: 4.
bef ore wrapping around with 0 bi ts: 1011 (5)
after wrapping around wi th 0 bi ts: 011 (3)
There is an overf low because the decimal number 5 is outside the range of values that can be
represented exactly by means of three bits. The MSB is truncated, and the result becomes
posi ti ve: 3.
Exampl e (unsi gned, 3-bit number):
bef ore wrapping around with 0 bi ts: 11011 (27)
after wrapping around wi th 0 bi ts: 011 (3)
SC_WRAP, n_bi ts > 0: SC_WRAP, 1
Whenever n_bi ts is greater than 0, the specif ied number of bits on the MSB si de of the result shal l be
saturated with preservati on of the ori ginal sign; the other bits shall be copied from the ori ginal. Posi ti ve
numbers shal l remain positive; negati ve numbers shal l remai n negative. Figure 6 ill ustrates the SC_WRAP
overfl ow mode for a word length of three bits wi th the n_bi ts parameter set to 1. The x axi s represents the
word l ength bef ore rounding; the y axi s represents the word l ength after rounding.
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
7 8 9 -7 -8 -9
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


312
Copyright 2012 IEEE. All rights reserved.
Figure 6Wrap-around with n_bits = 1 for signed numbers
Exampl es (si gned, 3-bit number):
bef ore wrapping around with 1 bi t: 0101 (5)
after wrapping around wi th 1 bi t: 001 (1)
There is an overfl ow because the deci mal number 5 is outsi de the range of val ues that can be
represented exactl y by means of three bits. The sign bit is kept, so that positi ve numbers remai n
posi ti ve.
bef ore wrapping around with 1 bi t: 1011 (5)
after wrapping around wi th 1 bi t: 111 (1)
There is an overf low because the decimal number 5 is outside the range of values that can be
represented exactly by means of three bi ts. The MSB i s truncated, but the si gn bi t is kept, so
that negative numbers remai n negative.
Exampl e (unsi gned, 5-bit number):
bef ore wrapping around with 3 bi ts: 0110010 (50)
after wrapping around wi th 3 bi ts: 11110 (30)
For thi s example the SC_WRAP, 3 mode i s appl ied. The result number is fi ve bits wi de. The
three bits at the MSB side are set to 1; the remaining bits are copi ed.
7.10.9.8 SC_WRAP_SM
The SC_WRAP_SM overfl ow mode shal l be used to i ndi cate that the output i s sign-magnitude wrapped
around i n the case of overf low. The n_bits parameter shall indicate the number of bits (f or exampl e, 1) on
the MSB side of the cast number that are saturated with preservati on of the original sign.
Two dif ferent cases are possibl e:
SC_WRAP_SM with parameter n_bi ts = 0
SC_WRAP_SM with parameter n_bi ts > 0
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
7 8 9 -7 -8 -9
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


313
Copyright 2012 IEEE. All rights reserved.
SC_WRAP_SM, 0
TheMSBs outsi detherequi red word length shall bedel eted. Thesign bit of theresul t shal l get theval ueof
thel east si gni fi cant of thedel eted bits. Theother bi tsshal l bei nverted i ncasewheretheorigi nal and thenew
val ues of the most significant of the kept bits differ. Otherwi se, the other bits shal l be copied from the
ori gi nal to theresul t.
Figure 7Sign magnitude wrap-around with n_bits = 0
Exampl e:
The sequence of operati ons to cast a decimal number 4 i nto three bi ts and use the overflow mode
SC_WRAP_SM, 0, as shown i nFi gure7, isasfol lows:
0100 (4)
Theoriginal representati on i struncated to beput in athree-bit number:
100(-4)
Thenew si gn bi t is 0. Thi si stheval ueof least signi fi cant deleted bi t.
Becausetheoriginal and thenew valueof thenew si gn bi t differ, thevaluesof theremai ni ngbitsare
inverted:
011(3)
This principle shall be appl ied to all numbersthat cannot berepresented exactly by means of three
bits, asshowni n Table43.
SC_WRAP_SM, n_bi ts > 0
Thefirst n_bi ts bitson theMSB si deof theresult number shal l beasfol lows:
Saturated to MAX in caseof apositivenumber
Saturated to MIN in case of a negative number
Al l numbersshal l retain their si gn.
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
7 8 9 -7 -8 -9
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


314
Copyright 2012 IEEE. All rights reserved.
I n case where n_bi ts equals 1, the other bits shall be copi ed and XORed wi th the ori ginal and the new value
of the sign bit of the result. In the case where n_bi ts i s greater than 1, the remai ni ng bits shall be XORed wi th
the ori gi nal val ue of the least si gni fi cant saturated bit and the inverse value of the original sign bit.
Exampl e:
SC_WRAP_SM, n_bi ts > 0: SC_WRAP_SM, 3
The f irst three bits on the MSB si de of the cast number are saturated to MAX or MIN.
I f the decimal number 234 is cast into fi ve bits using the overf low mode SC_WRAP_SM, 3, the fol lowi ng
happens:
011101010 (234)
The original representation is truncated to fi ve bits:
01010
The original sign bit i s copied to the new MSB (bit position 4, starting from bi t posi ti on 0):
01010
Table 43Sign magnitude wrap-around with n_bits = 0 for a three-bit number
Decimal Binar y
8 111
7 000
6 001
5 010
4 011
3 011
2 010
1 001
0 000
1 111
2 110
3 101
4 100
5 100
6 101
7 110
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


315
Copyright 2012 IEEE. All rights reserved.
The bits at posi ti on 2, 3, and 4 are saturated; they are converted to the maxi mum val ue that can be expressed
wi th three bits without changi ng the sign bit:
01110
The ori ginal val ue of the bi t on posi ti on 2 was 0. The remai ning bi ts at the LSB si de (10) are XORed with
thi s value and with the i nverse val ue of the ori ginal sign bi t, that is, wi th 0 and 1, respectively.
01101 (13)
Exampl e:
SC_WRAP_SM, n_bi ts > 0: SC_WRAP_SM, 1
The fi rst bi t on the MSB si de of the cast number gets the val ue of the ori ginal sign bit. The other bits are
copi ed and XORed wi th the origi nal and the new val ue of the sign bit of the result number.
Figure 8Sign magnitude wrap-around with n_bits = 1
The sequence of operations to cast the deci mal number 12 i nto three bi ts usi ng the overflow mode
SC_WRAP_SM, 1, as shown in Figure 8, is as fol lows:
01100 (12)
The original representation is truncated to three bits.
100
The original sign bit i s copied to the new MSB (bit position 2, starting from bi t posi ti on 0).
000
The two remaining bits at the LSB side are XORed wi th the origi nal (1) and the new val ue (0) of the new
sign bi t.
011
This principl e shal l be appli ed to all numbers that cannot be represented exactly by means of three bi ts, as
shown in Table 44.
1
1
2 3 4 5 6
2
3
4
5
-1
-2
-3
-4
-5
-1 -2 -3 -4 -5 -6
x
y
7 8 9 -7 -8 -9
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


316
Copyright 2012 IEEE. All rights reserved.
7.10.9.9 Quantization modes
Quantizati on shall be appli ed when the precision of the val ue assi gned to a f ixed-point variabl e exceeds the
precision of the fi xed-poi nt variable. I n SystemC, specif ic quanti zation modes shall be avai lable to control
the mappi ng to a representabl e value.
The mutual ly exclusi ve quanti zation modes li sted in Tabl e 45 shall be provi ded. The default quantizati on
mode shall be SC_TRN.
Table 44Sign-magnitude wrap-around with n_bits=1 for a three-bit number
Decimal Binar y
9 001
8 000
7 000
6 001
5 010
4 011
3 011
2 010
1 001
0 000
1 111
2 110
3 101
4 100
5 100
6 101
7 110
8 111
9 111
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


317
Copyright 2012 IEEE. All rights reserved.
Quantizati on is the mapping of a val ue that may not be preci sel y represented i n a speci fi c fi xed-poi nt
representation to a val ue that can be represented wi th arbitrary magnitude. I f a value can be precisel y
represented, quanti zation shal l not change the value. Al l the roundi ng modes shall map a val ue to the nearest
value that is representable. When there are two nearest representabl e values (the val ue i s half way between
them), the roundi ng modes shall provide dif ferent criteri a f or selection between the two. Both truncate
modes shal l map a posi tive val ue to the nearest representabl e val ue that is less than the value. SC_TRN
mode shall map a negative value to the nearest representable val ue that is less than the val ue, whi le
SC_TRN_ZERO shall map a negative value to the nearest representabl e val ue that i s greater than the val ue.
Each of the f ol lowi ng quantization modes i s f ol lowed by a fi gure. The i nput values are gi ven on the x axis
and the output values on the y axi s. Together they determine the quanti zation mode. In each fi gure, the
quantization mode specif ied by the respective keyword is combined wi th the i deal characteri stic. This i deal
characteristi c i s represented by the di agonal dashed li ne.
Before each quantization mode i s di scussed i n detai l, an overvi ew i s given of how the dif ferent quanti zati on
modes deal with quantizati on f or si gned and unsi gned fi xed-point numbers.
7.10.9.10 Quantization for signed fixed-point numbers
The following template contains a signed fixed-point number in twos complement representation before
and af ter a quanti zati on mode has been appl ied, and a number of f lags. The f lags are explained bel ow the
templ ate.
The f ollowi ng f lags and symbols are used i n the template just given and in Tabl e 46:
x represents a bi nary di git (0 or 1).
sR represents a si gn bi t.
R represents the remaini ng bits.
l R represents the least si gni fi cant remaining bit.
Table 45Quantization modes
Quantization mode Name
Roundi ng to pl us i nf i ni ty SC_RND
Roundi ng to zero SC_RND_ZERO
Roundi ng to minus i nf i ni ty SC_RND_MI N_I NF
Roundi ng to i nfi ni ty SC_RND_I NF
Convergent rounding SC_RND_CONV
Truncati on SC_TRN
Truncati on to zero SC_TRN_ZERO
x x x x x x x x x x x x x
x x x x x x x x
sR R R R R R R R l R mD D D D D D
x x
x
Before
After:
Flags:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


318
Copyright 2012 IEEE. All rights reserved.
mD represents the most signif icant del eted bi t.
D represents the deleted bi ts.
r represents the logical or of the deleted bi ts except f or the mD bi t in the templ ate just given. When
there are no remaining bits, r is false. This means that r is false when the two nearest numbers are at
equal di stance.
Tabl e 46 shows how a signed fi xed-poi nt number shall be cast f or each of the possible quanti zation modes in
cases where there i s quantizati on. I f the two nearest representable numbers are not at equal distance, the
result shal l be the nearest representable number. This shall be found by applying the SC_RND mode, that i s,
by adding the most si gni fi cant of the deleted bits to the remaini ng bits.
The second column in Table 46 contains the expressi on that shall be added to the remaining bi ts. I t shal l
eval uate to a one or a zero. The operators used i n the table are ! for a bitwise negation, | for a bitwise
OR, and & for a bi twi se AND.
Table 46Quantization handling for signed fixed-point numbers
Quantization mode Expr ession to be added
SC_RND mD
Add the most si gni f icant del eted bi t to the remai ni ng bi ts.
SC_RND_ZERO mD & (sR | r)
I f the most si gni f i cant del eted bi t i s 1 and ei ther the si gn bi t or at l east one
other del eted bi t i s 1, add 1 to the remai ni ng bi ts.
SC_RND_MI N_I NF mD & r
I f themost si gni f i cant del eted bi t i s 1 and at l east one other del eted bi t i s 1,
add 1 to the remai ni ng bi ts.
SC_RND_I NF mD & (! sR | r)
I f the most si gni f i cant del eted bi t i s 1 and ei ther the inverted val ue of the
si gn bit or at l east one other del eted bi t i s 1, add 1 to the remai ni ng bi ts.
SC_RND_CONV mD & (lR | r)
I f the most signi f i cant del eted bi t i s 1 and ei ther the l east si gni f i cant of the
remai ni ng bi ts or at l east one other del eted bi t i s 1, add 1 to the remai ni ng
bi ts.
SC_TRN 0
Copy the remai ni ng bi ts.
SC_TRN_ZERO sR & (mD | r)
I f the si gn bi t i s 1 and ei ther the most si gni f i cant deleted bi t or at l east one
other del eted bi t i s 1, add 1 to the remai ni ng bi ts.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


319
Copyright 2012 IEEE. All rights reserved.
7.10.9.11 Quantization for unsigned fixed-point numbers
The f ollowi ng template contai ns an unsi gned fi xed-poi nt number before and after a quantizati on mode has
been appl ied, and a number of fl ags. The fl ags are explained bel ow the templ ate.
The f ollowi ng f lags and symbols are used i n the template just given and in Tabl e 47:
x represents a bi nary di git (0 or 1).
R represents the remaini ng bits.
l R represents the least si gni fi cant remaining bit.
mD represents the most signif icant del eted bi t.
D represents the deleted bi ts.
r represents the logical or of the deleted bi ts except f or the mD bi t in the templ ate just given. When
there are no remaining bits, r is false. This means that r is false when the two nearest numbers are at
equal di stance.
Tabl e 47 shows how an unsi gned f ixed-point number shal l be cast for each of the possible quantizati on
modes in cases where there is quanti zation. I f the two nearest representabl e numbers are not at equal
distance, the resul t shal l be the nearest representabl e number. Thi s shal l be f ound for all the roundi ng modes
by applying the SC_RND mode, that is, by addi ng the most si gni fi cant of the del eted bits to the remaining
bits.
The second column in Table 47 contains the expressi on that shall be added to the remaining bi ts. I t shal l
evaluate to a one or a zero. The & operator used in the table represents a bitwise AND and the | a bitwise
OR.
NOTEFor all rounding modes, overfl ow can occur. One extra bi t on the MSB si de is needed to represent the resul t i n
f ul l preci si on.
7.10.9.12 SC_RND
The result shall be rounded to the nearest representabl e number by addi ng the most signif icant of the deleted
LSBs to the remai ning bi ts. This rule shall be used f or al l rounding modes when the two nearest
representabl e numbers are not at equal distance. When the two nearest representabl e numbers are at equal
distance, thi s rule impl ies that there i s roundi ng toward plus inf inity, as shown in Figure 9.
x x x x x x x x x x x x x
x x x x x x x x
R R R R R R R R l R mD D D D D D
x x
x
Before
After:
Flags:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


320
Copyright 2012 IEEE. All rights reserved.
Figure 9Rounding to plus infinity
Table 47Quantization handling for unsigned fixed-point numbers
Quantization mode Expr ession to be added
SC_RND mD
Add the most si gni f icant del eted bi t to the l ef t bi ts.
SC_RND_ZERO 0
Copy the remai ning bi ts.
SC_RND_MI N_I NF 0
Copy the remai ning bi ts.
SC_RND_I NF mD
Add the most si gni f icant del eted bi t to the l ef t bi ts.
SC_RND_CONV mD & (l R | r)
I f the most si gni f i cant del eted bi t i s 1 and ei ther thel east si gni f i cant
of the remai ni ng bi ts or at l east one other del eted bi t i s 1, add 1 to
the remai ni ng bits.
SC_TRN 0
Copy the remai ning bi ts.
SC_TRN_ZERO 0
Copy the remai ning bi ts.
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


321
Copyright 2012 IEEE. All rights reserved.
In Figure 9, the symbol q ref ers to the quantizati on step, that is, the resol ution of the data type.
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type sc_fixed<3,2,SC_RND>
bef ore roundi ng to pl us i nf ini ty: (1.25)
after roundi ng to pl us i nf ini ty: 01.1 (1.5)
There i s quantizati on because the decimal number 1.25 i s outside the range of val ues that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND> number. The most signif icant of
the del eted LSBs (1) i s added to the new LSB.
bef ore roundi ng to pl us i nf ini ty: 10.11 (1.25)
after roundi ng to pl us i nf ini ty: 11.0 (1)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND> number. The most signif icant of
the del eted LSBs (1) i s added to the new LSB.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assigned to numbers of type sc_ufixed<12,8,SC_RND>
bef ore roundi ng to pl us i nf ini ty: 00100110.01001111 (38.30859375)
after roundi ng to pl us i nf ini ty: 00100110.0101 (38.3125)
7.10.9.13 SC_RND_ZERO
I f the two nearest representable numbers are not at equal distance, the SC_RND_ZERO mode shal l be
appl ied.
I f the two nearest representable numbers are at equal di stance, the output shall be rounded toward 0, as
shown i n Fi gure 10. For positi ve numbers, the redundant bits on the LSB side shall be deleted. For negati ve
numbers, the most signif icant of the del eted LSBs shall be added to the remaini ng bits.
Figure 10Rounding to zero
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


322
Copyright 2012 IEEE. All rights reserved.
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type sc_fixed<3,2,SC_RND_ZERO>
bef ore roundi ng to zero: (1.25)
after roundi ng to zero: 01.0 (1)
There i s quantizati on because the decimal number 1.25 i s outside the range of val ues that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND_ZERO> number. The redundant
bits are omitted.
bef ore roundi ng to zero: 10.11 (1.25)
after roundi ng to zero: 11.0 (1)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactly by means of a sc_fixed<3,2,SC_RND_ZERO> number. The most
signif icant of the omitted LSBs (1) is added to the new LSB.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assi gned to numbers of type
sc_ufixed<12,8,SC_RND_ZERO>
bef ore roundi ng to zero: 000100110.01001 (38.28125)
after roundi ng to zero: 000100110.0100 (38.25)
7.10.9.14 SC_RND_MIN_INF
I f the two nearest representabl e numbers are not at equal di stance, the SC_RND_MI N_INF mode shal l be
appl ied.
I f the two nearest representabl e numbers are at equal distance, there shal l be rounding toward minus infi nity,
as shown i n Fi gure 11, by omi tting the redundant bi ts on the LSB side.
Figure 11Rounding to minus infinity
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


323
Copyright 2012 IEEE. All rights reserved.
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type
sc_fixed<3,2,SC_RND_M I N_I NF>
bef ore roundi ng to minus i nfi ni ty: 01.01 (1.25)
after roundi ng to minus i nf ini ty: 01.0 (1)
There i s quantizati on because the decimal number 1.25 i s outside the range of val ues that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND_M I N_I NF> number. The
surplus bi ts are truncated.
bef ore roundi ng to minus i nfi ni ty: 10.11 (1.25)
after roundi ng to minus i nf ini ty: 10.1 (1.5)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND_M I N_I NF> number. The
surplus bi ts are truncated.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assi gned to numbers of type
sc_ufixed<12,8,SC_RND_M I N_I NF>
bef ore roundi ng to minus i nfi ni ty: 000100110.01001 (38.28125)
after roundi ng to minus i nf ini ty: 000100110.0100 (38.25)
7.10.9.15 SC_RND_INF
Roundi ng shal l be performed if the two nearest representable numbers are at equal di stance.
For positive numbers, there shall be rounding toward plus infi ni ty if the LSB of the remai ni ng bits is 1 and
toward minus i nfini ty if the LSB of the remaining bits is 0, as shown in Figure 12.
For negati ve numbers, there shall be roundi ng toward minus inf inity if the LSB of the remai ning bits is 1 and
toward pl us inf inity if the LSB of the remai ning bi ts is 0, as shown i n Fi gure 12.
Figure 12Rounding to infinity
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


324
Copyright 2012 IEEE. All rights reserved.
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type sc_fixed<3,2,SC_RND_I NF>
bef ore roundi ng to infi nity: 01.01 (1.25)
after roundi ng to i nfi ni ty: 01.1 (1.5)
There i s quantizati on because the decimal number 1.25 i s outside the range of val ues that can
be represented exactl y by means of a sc_fixed<3,2,SC_RND_I NF> number. The most
signif icant of the del eted LSBs (1) i s added to the new LSB.
bef ore roundi ng to infi nity: 10.11 (1.25)
after roundi ng to i nfi ni ty: 10.1 (1.5)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactly by means of a sc_fixed<3,2,SC_RND_I NF> number. The surpl us bi ts
are truncated.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assi gned to numbers of type
sc_ufixed<12,8,SC_RND_I NF>
bef ore roundi ng to infi nity: 000100110.01001 (38.28125)
after roundi ng to i nfi ni ty: 000100110.0101 (38.3125)
7.10.9.16 SC_RND_CONV
I f the two nearest representable numbers are not at equal distance, the SC_RND_CONV mode shal l be
appl ied.
I f the two nearest representabl e numbers are at equal di stance, there shal l be roundi ng toward plus infi nity i f
the LSB of the remaining bits is 1. There shal l be rounding toward minus infi nity if the LSB of the remain-
ing bits i s 0. The characteristi cs are shown in Figure 13.
Figure 13Convergent rounding
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


325
Copyright 2012 IEEE. All rights reserved.
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type sc_fixed<3,2,SC_RND_CONV >
bef ore convergent roundi ng: 00.11 (0.75)
after convergent roundi ng: 01.0 (1)
There i s quantizati on because the decimal number 0.75 i s outside the range of val ues that can
be represented exactly by means of a sc_fixed<3,2,SC_RND_CONV > number. The surplus
bits are truncated, and the resul t i s rounded toward pl us inf ini ty.
bef ore convergent roundi ng: 10.11 (1.25)
after convergent roundi ng: 11.0 (1)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactly by means of a sc_fixed<3,2,SC_RND_CONV > number. The surplus
bits are truncated, and the resul t i s rounded toward pl us inf ini ty.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assi gned to numbers of type
sc_ufixed<12,8,SC_RND_CONV>
bef ore convergent roundi ng: 000100110.01001 (38.28125)
after convergent roundi ng: 000100110.0100 (38.25)
bef ore convergent roundi ng: 000100110.01011 (38.34375)
after convergent roundi ng: 000100110.0110 (38.375)
7.10.9.17 SC_TRN
SC_TRN shal l be the default quantizati on mode. The result shall be rounded toward minus inf inity; that i s,
the superf luous bits on the LSB si de shal l be deleted. A quanti zed number shal l be approximated by the f irst
representabl e number below its original value withi n the requi red bi t range.
NOTEIn scientific literature, this mode i s usual l y call ed value truncation.
The requi red characteri stics are shown i n Figure 14.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


326
Copyright 2012 IEEE. All rights reserved.
Figure 14Truncation
Exampl e (signed):
Numbers of type sc_fixed<4,2> are assigned to numbers of type sc_fixed<3,2,SC_TRN>
bef ore truncati on: 01.01 (1.25)
after truncati on: 01.0 (1)
There i s quantizati on because the decimal number 1.25 i s outside the range of val ues that can
be represented exactly by means of a sc_fixed<3,2,SC_TRN> number. The LSB is truncated.
bef ore truncati on: 10.11 (1.25)
after truncati on: 10.1 (1.5)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactly by means of a sc_fixed<3,2,SC_TRN> number. The LSB is truncated.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assigned to numbers of type sc_ufixed<12,8,SC_TRN>
bef ore truncati on: 00100110.01001111 (38.30859375)
after truncati on: 00100110.0100 (38.25)
7.10.9.18 SC_TRN_ZERO
For posi ti ve numbers, this quanti zation mode shall correspond to SC_TRN. For negative numbers, the resul t
shal l be rounded toward zero (SC_RND_ZERO); that i s, the superfluous bi ts on the right-hand side shall be
del eted and the sign bi t added to the left LSBs, provi ded at l east one of the deleted bits di ff ers from zero. A
quantized number shall be approxi mated by the f irst representable number that is lower i n absol ute val ue.
NOTEIn scientific literature, this mode is usually called magnitude truncation.
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


327
Copyright 2012 IEEE. All rights reserved.
The requi red characteri stics are shown i n Figure 15.
Figure 15Truncation to zero
Exampl e (signed):
A number of type sc_fixed<4,2> is assigned to a number of type sc_fixed<3,2,SC_TRN_ZERO>
bef ore truncati on to zero: 10.11 (1.25)
after truncati on to zero: 11.0 (1)
There is quantization because the decimal number 1.25 is outside the range of values that can
be represented exactly by means of a sc_fixed<3,2,SC_TRN_ZERO> number. The LSB i s
truncated, and then the sign bit (1) is added at the LSB side.
Exampl e (unsigned):
Numbers of type sc_ufixed<16,8> are assi gned to numbers of type
sc_ufixed<12,8,SC_TRN_ZERO>
bef ore truncati on to zero: 00100110.01001111 (38.30859375)
after truncati on to zero: 00100110.0100 (38.25)
7.10.10 sc_fxnum
7.10.10.1 Description
Cl ass sc_fxnum is the base cl ass f or fi nite-precision f ixed-point types. It shal l be provided in order to def ine
functi ons and overloaded operators that wil l work wi th any derived cl ass.
7.10.10.2 Class definition
namespace sc_dt {
class sc_fxnum
{
f ri end cl ass sc_fxval;
q
q
2q 3q
2q
3q
x
y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


328
Copyright 2012 IEEE. All rights reserved.
f ri end cl ass sc_fxnum_bi tr ef

;
f ri end cl ass sc_fxnum_subr ef

;
f ri end cl ass sc_fxnum_fast_bi tref

;
f ri end cl ass sc_fxnum_fast_subr ef

;
publ ic:
// Unary operators
const sc_f xval oper ator- () const;
const sc_f xval oper ator + () const;
// Binary operators
#def ine DECL_BI N_OP_T( op , tp ) \
f riend const sc_f xval operator op ( const sc_f xnum& , tp ); \
f riend const sc_f xval operator op ( tp , const sc_f xnum& );
#def ine DECL_BI N_OP_OTHER( op ) \
DECL_BIN_OP_T( op , int64 ) \
DECL_BIN_OP_T( op , uint64 ) \
DECL_BIN_OP_T( op , const sc_int_base& ) \
DECL_BIN_OP_T( op , const sc_uint_base& ) \
DECL_BIN_OP_T( op , const sc_signed& ) \
DECL_BIN_OP_T( op, const sc_unsi gned& )
#def ine DECL_BI N_OP( op , dummy ) \
f riend const sc_f xval operator op ( const sc_fxnum& , const sc_f xnum& ); \
DECL_BIN_OP_T( op , int ) \
DECL_BIN_OP_T( op , unsigned i nt ) \
DECL_BIN_OP_T( op , long ) \
DECL_BIN_OP_T( op , unsigned l ong ) \
DECL_BIN_OP_T( op , fl oat ) \
DECL_BIN_OP_T( op , double ) \
DECL_BIN_OP_T( op, const char* ) \
DECL_BIN_OP_T( op , const sc_f xval &) \
DECL_BIN_OP_T( op , const sc_f xval_f ast& ) \
DECL_BIN_OP_T( op , const sc_f xnum_f ast& ) \
DECL_BIN_OP_OTHER( op )
DECL_BI N_OP( * , mul t )
DECL_BIN_OP( + , add )
DECL_BIN_OP( - , sub )
DECL_BIN_OP( / , div )
#undef DECL_BI N_OP_T
#undef DECL_BI N_OP_OTHER
#undef DECL_BI N_OP
f riend const sc_f xval oper ator << ( const sc_fxnum& , int );
f riend const sc_f xval oper ator >> ( const sc_fxnum& , int );
// Relati onal (including equali ty) operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxnum& , tp ); \
f riend bool operator op ( tp , const sc_fxnum& ); \
DECL_REL_OP_T( op , int64 ) \
DECL_REL_OP_T( op , uint64 ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


329
Copyright 2012 IEEE. All rights reserved.
DECL_REL_OP_T( op , const sc_i nt_base& ) \
DECL_REL_OP_T( op , const sc_ui nt_base& ) \
DECL_REL_OP_T( op , const sc_si gned& ) \
DECL_REL_OP_T( op , const sc_unsigned& )
#def ine DECL_REL _OP( op ) \
f riend bool operator op ( const sc_fxnum& , const sc_f xnum& ); \
DECL_REL_OP_T( op , i nt ) \
DECL_REL_OP_T( op , unsi gned int ) \
DECL_REL_OP_T( op , l ong ) \
DECL_REL_OP_T( op , unsi gned long ) \
DECL_REL_OP_T( op , fl oat ) \
DECL_REL_OP_T( op , doubl e ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_T( op , const sc_f xval & ) \
DECL_REL_OP_T( op , const sc_f xval _fast& ) \
DECL_REL_OP_T( op , const sc_f xnum_f ast& ) \
DECL_REL_OP_OTHER( op )
DECL_REL_OP( < )
DECL_REL_OP( <= )
DECL_REL_OP( > )
DECL_REL_OP( >= )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
#undef DECL_REL_OP_T
#undef DECL_REL_OP_OTHER
#undef DECL_REL_OP
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f xnum& operator op( tp ); \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_f xnum_f ast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


330
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
sc_f xnum& oper ator ++ ();
sc_f xnum& oper ator-- ();
// Bit selecti on
const sc_fxnum_bi tref

oper ator [] ( i nt ) const;


sc_fxnum_bi tr ef

oper ator [] ( i nt );
// Part selection
const sc_fxnum_subr ef

oper ator () ( i nt , int ) const;


sc_fxnum_subr ef

oper ator () ( i nt , int );


const sc_fxnum_subr ef

r ange( i nt , int ) const;


sc_fxnum_subr ef

r ange( i nt , int );
const sc_fxnum_subr ef

oper ator () () const;


sc_fxnum_subr ef

oper ator () ();


const sc_fxnum_subr ef

r ange() const;
sc_fxnum_subr ef

r ange();
// Impl icit conversion
operator double() const;
// Expl icit conversi on to primiti ve types
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


331
Copyright 2012 IEEE. All rights reserved.
// Query val ue
bool is_neg() const;
bool is_zer o() const;
bool quantization_flag() const;
bool over flow_flag() const;
const sc_f xval value() const;
// Query parameters
int wl() const;
int iwl() const;
sc_q_mode q_mode() const;
sc_o_mode o_mode() const;
int n_bits() const;
const sc_f xtype_params& type_par ams() const;
const sc_f xcast_switch& cast_switch() const;
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
sc_fxnum();
sc_fxnum( const sc_fxnum& );
} ;
} // namespace sc_dt
7.10.10.3 Constraints on usage
An appl ication shall not di rectl y create an i nstance of type sc_fxnum. An appli cati on may use a pointer to
sc_fxnum or a reference to sc_fxnum to ref er to an object of a class derived from sc_fxnum.
7.10.10.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fxnum, usi ng truncation or si gn-extension, as descri bed in 7.10.4.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


332
Copyright 2012 IEEE. All rights reserved.
7.10.10.5 Implicit type conversion
operator double() const;
Operator double shall provide impl icit type conversi on f rom sc_fxnum to doubl e.
7.10.10.6 Explicit type conversion
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
These member functions shall perf orm conversi on to C++ numeri c types.
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
These member f unctions shall perf orm the conversion to a str ing representati on, as descri bed i n
7.2.11, 7.10.8, and 7.10.8.1.
7.10.11 sc_fxnum_fast
7.10.11.1 Description
Cl ass sc_fxnum_fast is the base cl ass f or li mited-preci sion f ixed-point types. It shall be provi ded in order to
def ine functions and overloaded operators that wil l work wi th any deri ved cl ass.
7.10.11.2 Class definition
namespace sc_dt {
class sc_fxnum_fast
{
f riend cl ass sc_fxval_fast;
f ri end cl ass sc_fxnum_bi tr ef

;
f ri end cl ass sc_fxnum_subr ef

;
f ri end cl ass sc_fxnum_fast_bi tref

;
f ri end cl ass sc_fxnum_fast_subr ef

;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


333
Copyright 2012 IEEE. All rights reserved.
publ ic:
// Unary operators
const sc_f xval _f ast oper ator- () const;
const sc_f xval _f ast oper ator + () const;
// Binary operators
#def ine DECL_BI N_OP_T( op , tp ) \
f riend const sc_f xval_f ast operator op ( const sc_fxnum_fast& , tp ); \
f riend const sc_f xval_f ast operator op ( tp , const sc_fxnum_fast& );
#def ine DECL_BI N_OP_OTHER( op ) \
DECL_BIN_OP_T( op , int64 ) \
DECL_BIN_OP_T( op , uint64 ) \
DECL_BIN_OP_T( op , const sc_int_base& ) \
DECL_BIN_OP_T( op , const sc_uint_base& ) \
DECL_BIN_OP_T( op , const sc_signed& ) \
DECL_BIN_OP_T( op, const sc_unsi gned& )
#def ine DECL_BI N_OP( op , dummy ) \
f riend const sc_f xval_f ast operator op ( const sc_f xnum_f ast& , const sc_fxnum_fast& ); \
DECL_BIN_OP_T( op , int ) \
DECL_BIN_OP_T( op , unsigned i nt ) \
DECL_BIN_OP_T( op , long ) \
DECL_BIN_OP_T( op , unsigned l ong ) \
DECL_BIN_OP_T( op , fl oat ) \
DECL_BIN_OP_T( op , double ) \
DECL_BIN_OP_T( op, const char* ) \
DECL_BIN_OP_T( op , const sc_f xval_f ast& ) \
DECL_BIN_OP_OTHER( op )
DECL_BI N_OP( * , mul t )
DECL_BIN_OP( + , add )
DECL_BIN_OP( - , sub )
DECL_BIN_OP( / , div )
#undef DECL_BI N_OP_T
#undef DECL_BI N_OP_OTHER
#undef DECL_BI N_OP
f riend const sc_f xval oper ator << ( const sc_fxnum_fast& , int );
f riend const sc_f xval oper ator >> ( const sc_fxnum_fast& , int );
// Relati onal (including equali ty) operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxnum_fast& , tp ); \
f riend bool operator op ( tp , const sc_fxnum_fast& );
DECL_REL_OP_T( op , int64 ) \
DECL_REL_OP_T( op , uint64 ) \
DECL_REL_OP_T( op , const sc_int_base& ) \
DECL_REL_OP_T( op , const sc_ui nt_base& ) \
DECL_REL_OP_T( op , const sc_signed& ) \
DECL_REL_OP_T( op , const sc_unsigned& )
#def ine DECL_REL _OP( op ) \
f riend bool operator op ( const sc_fxnum_fast& , const sc_f xnum_f ast& ); \
DECL_REL_OP_T( op , i nt ) \
DECL_REL_OP_T( op , unsi gned int ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


334
Copyright 2012 IEEE. All rights reserved.
DECL_REL_OP_T( op , l ong ) \
DECL_REL_OP_T( op , unsi gned long ) \
DECL_REL_OP_T( op , fl oat ) \
DECL_REL_OP_T( op , doubl e ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_T( op , const sc_f xval _fast& ) \
DECL_REL_OP_OTHER( op )
DECL_REL_OP( < )
DECL_REL_OP( <= )
DECL_REL_OP( > )
DECL_REL_OP( >= )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
#undef DECL_REL_OP_T
#undef DECL_REL_OP_OTHER
#undef DECL_REL_OP
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f xnum& operator op( tp ); \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_f xnum_f ast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval _f ast oper ator ++ ( i nt );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


335
Copyright 2012 IEEE. All rights reserved.
const sc_f xval _f ast oper ator-- ( i nt );
sc_f xnum_f ast& oper ator ++ ();
sc_f xnum_f ast& oper ator-- ();
// Bit selecti on
const sc_fxnum_bi tref

oper ator [] ( i nt ) const;


sc_fxnum_bi tr ef

oper ator [] ( i nt );
// Part selection
const sc_fxnum_fast_subr ef

oper ator () ( i nt , int ) const;


sc_fxnum_fast_subr ef

oper ator () ( i nt , int );


const sc_fxnum_fast_subr ef

r ange( i nt , int ) const;


sc_fxnum_fast_subr ef

r ange( i nt , int );
const sc_fxnum_fast_subr ef

oper ator () () const;


sc_fxnum_fast_subr ef

oper ator () ();


const sc_fxnum_fast_subr ef

r ange() const;
sc_fxnum_fast_subr ef

r ange();
// Impl icit conversion
operator double() const;
// Expl icit conversi on to primiti ve types
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
// Query val ue
bool is_neg() const;
bool is_zer o() const;
bool quantization_flag() const;
bool over flow_flag() const;
const sc_f xval _f ast value() const;
// Query parameters
int wl() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


336
Copyright 2012 IEEE. All rights reserved.
int iwl() const;
sc_q_mode q_mode() const;
sc_o_mode o_mode() const;
int n_bits() const;
const sc_f xtype_params& type_par ams() const;
const sc_f xcast_switch& cast_switch() const;
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
sc_fxnum_fast();
sc_fxnum_fast( const sc_fxnum_fast& );
} ;
} // namespace sc_dt
7.10.11.3 Constraints on usage
An appli cation shal l not di rectl y create an instance of type sc_fxnum_fast. An appl icati on may use a pointer
to sc_fxnum_fast or a reference to sc_fxnum_fast to ref er to an object of a cl ass derived f rom
sc_fxnum_fast.
7.10.11.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fxnum_fast, usi ng truncation or si gn-extensi on, as descri bed in 7.10.4.
7.10.11.5 Implicit type conversion
operator double() const;
Operator double shall provide impl icit type conversi on f rom sc_fxnum_fast to doubl e.
7.10.11.6 Explicit type conversion
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
These member functions shall perf orm conversi on to C++ numeri c types.
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


337
Copyright 2012 IEEE. All rights reserved.
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
These member f unctions shall perf orm the conversion to a str ing representati on, as descri bed i n
7.2.11, 7.10.8, and 7.10.8.1.
7.10.12 sc_fxval
7.10.12.1 Description
Cl ass sc_fxval i s the vari abl e-precision fi xed-poi nt type. It may hol d the val ue of any of the fi xed-point
types and perf orm the variable-precision f ixed-point ari thmeti c operations. Type casting shal l be perf ormed
by the f ixed-poi nt types themselves. Limited variable-preci si on type sc_fxval_fast and variable-preci si on
type sc_fxval may be mi xed freel y.
7.10.12.2 Class definition
namespace sc_dt {
class sc_fxval
{
publ ic:
// Constructors and destructor
sc_fxval();
expl icit sc_fxval( i nt );
expl icit sc_fxval( unsigned int );
expl icit sc_fxval( l ong );
expl icit sc_fxval( unsigned l ong );
expl icit sc_fxval( f loat );
expl icit sc_fxval( double );
expl icit sc_fxval( const char* );
sc_fxval( const sc_fxval & );
sc_fxval( const sc_fxval_fast& );
sc_fxval( const sc_fxnum& );
sc_fxval( const sc_fxnum_fast& );
expl icit sc_fxval( i nt64 );
expl icit sc_fxval( ui nt64 );
expl icit sc_fxval( const sc_int_base& );
expl icit sc_fxval( const sc_uint_base& );
expl icit sc_fxval( const sc_si gned& );
expl icit sc_fxval( const sc_unsigned& );
~sc_fxval();
// Unary operators
const sc_f xval oper ator- () const;
const sc_f xval & oper ator + () const;
f riend voi d neg( sc_fxval & , const sc_f xval& );
// Binary operators
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


338
Copyright 2012 IEEE. All rights reserved.
#def ine DECL_BI N_OP_T( op , tp ) \
f riend const sc_f xval operator op ( const sc_f xval & , tp ); \
f riend const sc_f xval operator op ( tp , const sc_fxval & );
#def ine DECL_BI N_OP_OTHER( op ) \
DECL_BIN_OP_T( op , int64 ) \
DECL_BIN_OP_T( op , uint64 ) \
DECL_BIN_OP_T( op , const sc_i nt_base& ) \
DECL_BIN_OP_T( op , const sc_uint_base& ) \
DECL_BIN_OP_T( op , const sc_signed& ) \
DECL_BIN_OP_T( op , const sc_unsi gned& )
#def ine DECL_BI N_OP( op , dummy ) \
f riend const sc_f xval operator op ( const sc_fxval & , const sc_f xval& ); \
DECL_BIN_OP_T( op , int ) \
DECL_BIN_OP_T( op , unsigned int ) \
DECL_BIN_OP_T( op , long ) \
DECL_BIN_OP_T( op , unsigned l ong ) \
DECL_BIN_OP_T( op , fl oat ) \
DECL_BIN_OP_T( op , double ) \
DECL_BIN_OP_T( op , const char* ) \
DECL_BIN_OP_T( op , const sc_f xval_f ast& ) \
DECL_BIN_OP_T( op , const sc_f xnum_f ast& ) \
DECL_BIN_OP_OTHER( op )
DECL_BIN_OP( * , mul t )
DECL_BIN_OP( + , add )
DECL_BIN_OP( - , sub )
DECL_BIN_OP( / , div )
f riend const sc_f xval oper ator << ( const sc_fxval & , int );
f riend const sc_f xval oper ator >> ( const sc_fxval & , int );
// Relati onal (including equali ty) operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxval& , tp ); \
f riend bool operator op ( tp , const sc_fxval & );
#def ine DECL_REL _OP_OTHER( op ) \
DECL_REL_OP_T( op , i nt64 ) \
DECL_REL_OP_T( op , uint64 ) \
DECL_REL_OP_T( op , const sc_int_base& ) \
DECL_REL_OP_T( op , const sc_ui nt_base& ) \
DECL_REL_OP_T( op , const sc_si gned& ) \
DECL_REL_OP_T( op , const sc_unsigned& )
#def ine DECL_REL _OP( op ) \
friend bool operator op ( const sc_fxval & , const sc_f xval & ); \
DECL_REL_OP_T( op , int ) \
DECL_REL_OP_T( op , unsigned int ) \
DECL_REL_OP_T( op , long ) \
DECL_REL_OP_T( op , unsigned l ong ) \
DECL_REL_OP_T( op , fl oat ) \
DECL_REL_OP_T( op , double ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_T( op , const sc_f xval_f ast& ) \
DECL_REL_OP_T( op , const sc_f xnum_f ast& ) \
DECL_REL_OP_OTHER( op )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


339
Copyright 2012 IEEE. All rights reserved.
DECL_REL_OP( < )
DECL_REL_OP( <= )
DECL_REL_OP( > )
DECL_REL_OP( >= )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f xval& operator op( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
// Auto-increment and auto-decrement
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
sc_f xval& oper ator ++ ();
sc_f xval& oper ator-- ();
// Impl icit conversion
operator double() const;
// Expl icit conversi on to primiti ve types
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


340
Copyright 2012 IEEE. All rights reserved.
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
// Expl icit conversi on to character string
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
// Methods
bool is_neg() const;
bool is_zer o() const;
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
} ;
} // namespace sc_dt
7.10.12.3 Constraints on usage
A sc_fxval object that i s decl ared without an i nitial val ue shall be uninitial ized (unless i t is decl ared as static,
in which case it shall be initiali zed to zero). Uninitiali zed obj ects may be used wherever an initiali zed obj ect
is permi tted. The result of an operation on an uni nitiali zed obj ect i s undefi ned.
7.10.12.4 Public constructors
The constructor argument shal l be taken as the ini ti al val ue of the sc_fxval obj ect. The def aul t constructor
shall not ini tial ize the value.
7.10.12.5 Operators
The operators that shal l be defi ned f or sc_fxval are gi ven in Tabl e 48.
oper ator << and oper ator >> def ine arithmeti c shif ts that perform si gn extensi on.
The types of the operands shal l be as def ined i n 7.10.4.
7.10.12.6 Implicit type conversion
operator double() const;
Operator double can be used f or implici t type conversion to the C++ type double.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


341
Copyright 2012 IEEE. All rights reserved.
7.10.12.7 Explicit type conversion
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_i nt() const;
unsi gned int to_uint() const;
long to_l ong() const;
unsi gned longto_ulong() const;
int64 to_i nt64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl eto_double() const;
Thesemember functions shall perform theconversi on totherespectiveC++ numeric types.
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep) const;
const std::string to_str ing( sc_numrep, bool ) const;
const std::string to_str ing( sc_fmt ) const;
const std::string to_str ing( sc_numrep, sc_fmt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
These member functions shall perform the conversion to a str ing representati on, as descri bed i n
7.2.11, 7.10.8, and 7.10.8.1.
7.10.13 sc_fxval_fast
7.10.13.1 Description
Typesc_fxval _fast i s the l imi ted vari able-preci si on fi xed-poi nt type and shall be l imi ted to a mantissa of
53 bi ts. It may hold the value of any of the fixed-point types and shall be used to perform the l imi ted
variable-preci si on fi xed-point ari thmeti c operations. Li mited variable-precisi on fixed-point type
sc_fxval_fast and vari able-preci si onfixed-point typesc_fxval may bemi xed freel y.
Table 48Operators for sc_fxval
Oper ator class Oper ators in class
Arithmetic * / + - << >> ++ --
Equality == !=
Relational <<= >>=
Assignment = *= /= += -= <<= >>=
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


342
Copyright 2012 IEEE. All rights reserved.
7.10.13.2 Class definition
namespace sc_dt {
class sc_fxval_fast
{
publ ic:
sc_fxval_fast();
expl icit sc_fxval_fast( i nt );
expl icit sc_fxval_fast( unsigned i nt );
expl icit sc_fxval_fast( l ong );
expl icit sc_fxval_fast( unsigned l ong );
expl icit sc_fxval_fast( f loat );
expl icit sc_fxval_fast( double );
expl icit sc_fxval_fast( const char* );
sc_fxval_fast( const sc_fxval & );
sc_fxval_fast( const sc_fxval_fast& );
sc_fxval_fast( const sc_fxnum& );
sc_fxval_fast( const sc_fxnum_fast& );
expl icit sc_fxval_fast( i nt64 );
expl icit sc_fxval_fast( ui nt64 );
expl icit sc_fxval_fast( const sc_int_base& );
expl icit sc_fxval_fast( const sc_uint_base& );
expl icit sc_fxval_fast( const sc_si gned& );
expl icit sc_fxval_fast( const sc_unsigned& );
~sc_fxval_fast();
// Unary operators
const sc_f xval _f ast oper ator- () const;
const sc_f xval _f ast& oper ator + () const;
// Binary operators
#def ine DECL_BI N_OP_T( op , tp ) \
f riend const sc_f xval_f ast operator op ( const sc_fxval _fast& , tp ); \
f riend const sc_fxval_fast operator op ( tp , const sc_f xval_f ast& );
#def ine DECL_BI N_OP_OTHER( op ) \
DECL_BIN_OP_T( op , int64 ) \
DECL_BIN_OP_T( op , uint64 ) \
DECL_BIN_OP_T( op , const sc_int_base& ) \
DECL_BIN_OP_T( op , const sc_uint_base& ) \
DECL_BIN_OP_T( op , const sc_signed& ) \
DECL_BIN_OP_T( op , const sc_unsi gned& )
#def ine DECL_BI N_OP( op , dummy ) \
f riend const sc_f xval_f ast operator op ( const sc_f xval _f ast& , const sc_fxval_f ast& ); \
DECL_BIN_OP_T( op , int ) \
DECL_BIN_OP_T( op , unsigned i nt ) \
DECL_BIN_OP_T( op , long ) \
DECL_BIN_OP_T( op , unsigned l ong ) \
DECL_BIN_OP_T( op , fl oat ) \
DECL_BIN_OP_T( op , double ) \
DECL_BIN_OP_T( op , const char* ) \
DECL_BIN_OP_OTHER( op )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


343
Copyright 2012 IEEE. All rights reserved.
DECL_BI N_OP( * , mul t )
DECL_BIN_OP( + , add )
DECL_BIN_OP( - , sub )
DECL_BIN_OP( / , div )
f riend const sc_f xval_f ast oper ator << ( const sc_fxval _fast& , int );
f riend const sc_f xval_f ast oper ator >> ( const sc_fxval _fast& , int );
// Relati onal (including equali ty) operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxval_fast& , tp );\
f riend bool operator op ( tp , const sc_fxval_fast& );
#def ine DECL_REL _OP_OTHER( op ) \
DECL_REL_OP_T( op , int64 ) \
DECL_REL_OP_T( op , uint64 ) \
DECL_REL_OP_T( op , const sc_int_base& ) \
DECL_REL_OP_T( op , const sc_ui nt_base& ) \
DECL_REL_OP_T( op , const sc_signed& ) \
DECL_REL_OP_T( op , const sc_unsigned& )
#def ine DECL_REL _OP( op ) \
f riend bool operator op ( const sc_fxval_fast& , const sc_f xval _f ast& ); \
DECL_REL_OP_T( op , i nt ) \
DECL_REL_OP_T( op , unsi gned int ) \
DECL_REL_OP_T( op , l ong ) \
DECL_REL_OP_T( op , unsi gned long ) \
DECL_REL_OP_T( op , fl oat ) \
DECL_REL_OP_T( op , doubl e ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_OTHER( op )
DECL_REL_OP( < )
DECL_REL_OP( <= )
DECL_REL_OP( > )
DECL_REL_OP( >= )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) sc_f xval _f ast& operator op( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


344
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( top )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
// Auto-increment and auto-decrement
const sc_f xval _f ast oper ator ++ ( i nt );
const sc_f xval _f ast oper ator-- ( i nt );
sc_f xval_f ast& oper ator ++ ();
sc_f xval_f ast& oper ator-- ();
// Impl icit conversion
oper ator double() const;
// Expl icit conversi on to primiti ve types
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
// Expl icit conversion to character stri ng
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool, sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
// Other methods
bool is_neg() const;
bool is_zer o() const;
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
voi d dump( std::ostream& = std::cout ) const;
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


345
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_dt
7.10.13.3 Constraints on usage
A sc_fxval_fast object that i s declared wi thout an i ni ti al val ue shal l be unini ti ali zed (unless i t i s declared as
stati c, i n whi ch case i t shal l be i nitiali zed to zero). Unini ti al ized objects may be used wherever an i nitiali zed
object is permitted. The result of an operation on an uni niti ali zed obj ect i s undef i ned.
7.10.13.4 Public constructors
The constructor argument shal l be taken as the i nitial val ue of the sc_fxval_fast object. The def aul t
constructor shall not ini tial ize the value.
7.10.13.5 Operators
The operators that shal l be defi ned f or sc_fxval_fast are given i n Table 49.
NOTEoper ator << and oper ator >> def i ne ari thmeti c shi f ts, not bi twi se shi fts. The di f f erence i s that no bi ts are l ost
and proper si gn extensi on i s done. Hence, these operators are al so wel l def ined f or si gned types, such as sc_fxval_fast.
7.10.13.6 Implicit type conversion
operator double() const;
Operator double can be used f or implici t type conversion to the C++ type double.
7.10.13.7 Explicit type conversion
short to_shor t() const;
unsi gned short to_ushor t() const;
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
fl oat to_float() const;
doubl e to_double() const;
These member functions shall perf orm the conversi on to the respective C++ numeric types.
Table 49Operators for sc_fxval_fast
Oper ator class Oper ator s in class
Ari thmeti c * / + - << >> ++ --
Equal i ty == ! =
Relati onal <<= >>=
Assi gnment = * = /= += -= <<= >>=
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


346
Copyright 2012 IEEE. All rights reserved.
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
const std::string to_str ing( sc_f mt ) const;
const std::string to_str ing( sc_numrep , sc_f mt ) const;
const std::string to_str ing( sc_numrep , bool , sc_fmt ) const;
const std::string to_dec() const;
const std::string to_bin() const;
const std::string to_oct() const;
const std::string to_hex() const;
These member f unctions shall perf orm the conversion to a str ing representati on, as descri bed i n
7.2.11, 7.10.8, and 7.10.8.1.
7.10.14 sc_fix
7.10.14.1 Description
Cl ass sc_fix shall represent a signed (twos complement) fi nite-preci si on fi xed-poi nt value. The f ixed-point
type parameters wl, iwl, q_mode, o_mode, and n_bitsmay be specif ied as constructor arguments.
7.10.14.2 Class definition
namespace sc_dt {
class sc_fix
: publi c sc_f xnum
{
publ ic:
// Constructors and destructor
sc_fix();
sc_fix( i nt , int );
sc_fix( sc_q_mode , sc_o_mod e );
sc_fix( sc_q_mode , sc_o_mode, i nt );
sc_fix( i nt , int , sc_q_mode , sc_o_mode );
sc_fix( i nt , int , sc_q_mode, sc_o_mode, i nt );
sc_fix( const sc_fxcast_swi tch& );
sc_fix( i nt , int , const sc_fxcast_switch& );
sc_fix( sc_q_mode , sc_o_mode , const sc_fxcast_switch& );
sc_fix( sc_q_mode , sc_o_mode , i nt , const sc_f xcast_swi tch& );
sc_fix( i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_switch& );
sc_fix( i nt , int , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& );
sc_fix( const sc_fxtype_params& );
sc_fix( const sc_fxtype_params& , const sc_f xcast_switch& );
#def ine DECL_CTORS_T( tp ) \
sc_f ix( tp , i nt, int ); \
sc_f ix( tp , sc_q_mode , sc_o_mode ); \
sc_f ix( tp , sc_q_mode , sc_o_mode, i nt ); \
sc_f ix( tp , i nt , int , sc_q_mode , sc_o_mode ); \
sc_f ix( tp , int , i nt , sc_q_mode , sc_o_mode , i nt ); \
sc_f ix( tp , const sc_fxcast_switch& ); \
sc_f ix( tp , i nt , int , const sc_f xcast_switch& ); \
sc_f ix( tp , sc_q_mode , sc_o_mode , const sc_f xcast_switch& ); \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


347
Copyright 2012 IEEE. All rights reserved.
sc_f ix( tp , sc_q_mode , sc_o_mode , i n , const sc_f xcast_switch& ); \
sc_f ix( tp , i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_swi tch& ); \
sc_f ix( tp , i nt, int , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& ); \
sc_f ix( tp , const sc_fxtype_params& ); \
sc_f ix( tp , const sc_fxtype_params& , const sc_f xcast_swi tch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_f ix( tp ); \
DECL_CTORS_T( tp )
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_fi x( tp ); \
DECL_CTORS_T( tp )
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
sc_fix( const sc_fi x& );
// Unary bi twi se operators
const sc_f ix oper ator ~ () const;
// Binary bitwise operators
f riend const sc_fix oper ator & ( const sc_fi x& , const sc_fi x& );
f riend const sc_fix oper ator & ( const sc_fi x& , const sc_fi x_f ast& );
f riend const sc_fix oper ator & ( const sc_fi x_f ast& , const sc_fi x& );
f riend const sc_fix oper ator | ( const sc_fi x& , const sc_fi x& );
f riend const sc_fix oper ator | ( const sc_fi x& , const sc_fi x_f ast& );
f riend const sc_fix oper ator | ( const sc_fi x_f ast& , const sc_fi x& );
f riend const sc_fix oper ator ^ ( const sc_fi x& , const sc_fi x& );
f riend const sc_fix oper ator ^ ( const sc_fi x& , const sc_fi x_f ast& );
f riend const sc_fix oper ator ^ ( const sc_fi x_f ast& , const sc_fi x& );
sc_f ix& oper ator = ( const sc_fi x& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f ix& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


348
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* )\
DECL_ASN_OP_T( op , const sc_fxval& )\
DECL_ASN_OP_T( op , const sc_fxval _fast& )\
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_f ix& )
DECL_ASN_OP_T( &= , const sc_f ix_fast& )
DECL_ASN_OP_T( |= , const sc_f ix& )
DECL_ASN_OP_T( |= , const sc_f ix_fast& )
DECL_ASN_OP_T( ^= , const sc_f ix& )
DECL_ASN_OP_T( ^= , const sc_f ix_fast& )
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
sc_f ix& oper ator ++ ();
sc_f ix& oper ator-- ();
} ;
} // namespace sc_dt
7.10.14.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
7.10.14.4 Public constructors
The constructor arguments may speci fy the fi xed-point type parameters, as descri bed in 7.10.1. The default
constructor shall set f ixed-point type parameters according to the fi xed-point context in scope at the point of
construction. An i ni ti al val ue may additional ly be speci fi ed as a C++ or SystemC numeric obj ect or as a
string l iteral. A fi xed-point cast swi tch may also be passed as a constructor argument to set the f ixed-poi nt
casting, as described in 7.10.7.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


349
Copyright 2012 IEEE. All rights reserved.
7.10.14.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fix, usi ng truncation or si gn-extensi on, as descri bed in 7.10.4.
7.10.14.6 Bitwise operators
Bitwi se operators for al l combi nati ons of operands of type sc_fix and sc_fix_fast shall be defi ned, as
descri bed in 7.10.4.
7.10.15 sc_ufix
7.10.15.1 Description
Cl ass sc_ufix shall represent an unsi gned f ini te-precision fi xed-poi nt value. The fi xed-point type parameters
wl, iwl, q_mode, o_mode, and n_bits may be specif ied as constructor arguments.
7.10.15.2 Class definition
namespace sc_dt {
class sc_ufix
: publi c sc_f xnum
{
publ ic:
// Constructors
expl icit sc_ufix();
sc_ufix( i nt , int );
sc_ufix( sc_q_mode , sc_o_mode );
sc_ufix( sc_q_mode , sc_o_mode , i nt );
sc_ufix( i nt , int , sc_q_mode , sc_o_mode );
sc_ufix( i nt , int , sc_q_mode , sc_o_mode, int );
expl icit sc_ufix( const sc_fxcast_swi tch& );
sc_ufix( i nt , int , const sc_f xcast_switch& );
sc_ufix( sc_q_mode , sc_o_mode , const sc_f xcast_switch& );
sc_ufix( sc_q_mode , sc_o_mode , i nt , const sc_fxcast_swi tch& );
sc_ufix( i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_switch& );
sc_ufix( i nt , int , sc_q_mode , sc_o_mode , i nt , const sc_fxcast_swi tch& );
expl icit sc_ufix( const sc_fxtype_params& );
sc_ufix( const sc_fxtype_params& , const sc_f xcast_switch& );
#def ine DECL_CTORS_T( tp ) \
sc_ufi x( tp , int , i nt ); \
sc_ufi x( tp , sc_q_mode , sc_o_mode ); \
sc_ufi x( tp , sc_q_mode , sc_o_mode , int ); \
sc_ufi x( tp , int , i nt , sc_q_mode , sc_o_mode ); \
sc_ufi x( tp , int , i nt , sc_q_mode , sc_o_mode , int ); \
sc_ufi x( tp , const sc_f xcast_switch& ); \
sc_ufi x( tp , int , i nt , const sc_f xcast_switch& ); \
sc_ufi x( tp , sc_q_mode , sc_o_mode , const sc_f xcast_switch& ); \
sc_ufi x( tp , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& ); \
sc_ufi x( tp , int , i nt , sc_q_mode , sc_o_mode , const sc_f xcast_swi tch& ); \
sc_ufi x( tp , int , i nt , sc_q_mode , sc_o_mode , int , const sc_f xcast_switch& ); \
sc_ufi x( tp , const sc_f xtype_params& ); \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


350
Copyright 2012 IEEE. All rights reserved.
sc_ufi x( tp , const sc_f xtype_params& , const sc_f xcast_swi tch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_ufi x( tp ); \
DECL_CTORS_T( tp )
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_uf ix( tp ); \
DECL_CTORS_T( tp )
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
#undef DECL_CTORS_T
#undef DECL_CTORS_T_A
#undef DECL_CTORS_T_B
// Copy constructor
sc_ufix( const sc_uf ix& );
// Unary bi twi se operators
const sc_uf ix oper ator ~ () const;
// Binary bitwise operators
f riend const sc_ufi x oper ator & ( const sc_ufi x& , const sc_uf ix& );
f riend const sc_ufi x oper ator & ( const sc_ufi x& , const sc_uf ix_f ast& );
f riend const sc_ufi x oper ator & ( const sc_uf ix_f ast& , const sc_uf ix& );
f riend const sc_ufi x oper ator | ( const sc_ufi x& , const sc_uf ix& );
f riend const sc_ufi x oper ator | ( const sc_ufix& , const sc_uf ix_fast& );
f riend const sc_ufi x oper ator | ( const sc_uf ix_f ast& , const sc_uf ix& );
f riend const sc_ufi x oper ator ^ ( const sc_ufi x& , const sc_uf ix& );
f riend const sc_ufi x oper ator ^ ( const sc_ufi x& , const sc_uf ix_f ast& );
f riend const sc_ufi x oper ator ^ ( const sc_ufix_f ast& , const sc_ufix& );
// Assi gnment operators
sc_ufi x& oper ator = ( const sc_uf ix& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


351
Copyright 2012 IEEE. All rights reserved.
#def ine DECL_ASN_OP_T( op , tp ) \
sc_ufi x& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& )\
DECL_ASN_OP_T( op , const sc_uint_base& )\
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* )\
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& )\
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_uf ix& )
DECL_ASN_OP_T( &= , const sc_uf ix_fast& )
DECL_ASN_OP_T( |= , const sc_ufi x& )
DECL_ASN_OP_T( |= , const sc_uf ix_fast& )
DECL_ASN_OP_T( ^= , const sc_uf ix& )
DECL_ASN_OP_T( ^= , const sc_uf ix_fast& )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
sc_ufi x& oper ator ++ ();
sc_ufi x& oper ator-- ();
} ;
} // namespace sc_dt
7.10.15.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


352
Copyright 2012 IEEE. All rights reserved.
7.10.15.4 Public constructors
The constructor arguments may speci fy the fi xed-point type parameters, as descri bed in 7.10.1. The default
constructor shall set f ixed-point type parameters according to the fi xed-point context in scope at the point of
construction. An i ni ti al val ue may additional ly be speci fi ed as a C++ or SystemC numeric obj ect or as a
string l iteral. A fi xed-point cast swi tch may also be passed as a constructor argument to set the f ixed-poi nt
casting, as described in 7.10.7.
7.10.15.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_ufix, usi ng truncation or si gn-extensi on, as descri bed i n 7.10.4.
7.10.15.6 Bitwise operators
Bitwi se operators for al l combi nations of operands of type sc_ufix and sc_ufix_fast shal l be def ined, as
descri bed in 7.10.4.
7.10.16 sc_fix_fast
7.10.16.1 Description
Cl ass sc_fix_fast shall represent a signed (twos complement) limited-precision fixed-point value. The
f ixed-poi nt type parameters wl, iwl, q_mode, o_mode, and n_bits may be specif ied as constructor
arguments.
7.10.16.2 Class definition
namespace sc_dt {
class sc_fix_fast
: publi c sc_f xnum_f ast
{
publ ic:
// Constructors
sc_fix_fast();
sc_fix_fast( i nt , int );
sc_fix_fast( sc_q_mode , sc_o_mode );
sc_fix_fast( sc_q_mode , sc_o_mode , i nt );
sc_fix_fast( i nt , int , sc_q_mode , sc_o_mode );
sc_fix_fast( int , i nt , sc_q_mode , sc_o_mode , int );
sc_fix_fast( const sc_fxcast_switch& );
sc_fix_fast( i nt , int , const sc_f xcast_switch& );
sc_fix_fast( sc_q_mode , sc_o_mode , const sc_fxcast_switch& );
sc_fix_fast( sc_q_mode , sc_o_mode , i nt , const sc_f xcast_swi tch& );
sc_fix_fast( i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_switch& );
sc_fix_fast( i nt , int , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& );
sc_fix_fast( const sc_fxtype_params& );
sc_fix_fast( const sc_fxtype_params& , const sc_f xcast_switch& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


353
Copyright 2012 IEEE. All rights reserved.
#def ine DECL_CTORS_T( tp ) \
sc_f ix_fast( tp , i nt , int ); \
sc_f ix_fast( tp , sc_q_mode , sc_o_mode ); \
sc_f ix_fast( tp , sc_q_mode , sc_o_mode , i nt ); \
sc_f ix_fast( tp , i nt , int , sc_q_mode , sc_o_mode ); \
sc_f ix_fast( tp , i nt , int , sc_q_mode , sc_o_mode , int ); \
sc_f ix_fast( tp , const sc_fxcast_switch& ); \
sc_f ix_fast( tp , i nt , int , const sc_f xcast_switch& ); \
sc_f ix_fast( tp , sc_q_mode , sc_o_mode , const sc_f xcast_switch& ); \
sc_f ix_fast( tp , sc_q_mod e, sc_o_mode , i nt , const sc_fxcast_swi tch& ); \
sc_f ix_fast( tp , i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_switch& ); \
sc_f ix_fast( tp , i nt , int , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& ); \
sc_f ix_fast( tp , const sc_fxtype_params& ); \
sc_f ix_fast( tp , const sc_fxtype_params& , const sc_f xcast_switch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_f ix_fast( tp ); \
DECL_CTORS_T( tp )
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_fi x_f ast( tp ); \
DECL_CTORS_T( tp )
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
// Copy constructor
sc_fix_fast( const sc_fi x_f ast& );
// Operators
const sc_f ix_fast oper ator ~ () const;
f riend const sc_fi x_fast oper ator & ( const sc_fi x_f ast& , const sc_fi x_f ast& );
f riend const sc_fi x_fast oper ator ^ ( const sc_fi x_f ast& , const sc_fi x_f ast& );
f riend const sc_fi x_fast oper ator | ( const sc_fi x_f ast& , const sc_fi x_f ast& );
sc_f ix_fast& oper ator = ( const sc_fi x_f ast& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f ix_fast& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


354
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP_T( op , const sc_int_base& )\
DECL_ASN_OP_T( op , const sc_uint_base& )\
DECL_ASN_OP_T( op , const sc_si gned& )\
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* )\
DECL_ASN_OP_T( op , const sc_fxval& )\
DECL_ASN_OP_T( op , const sc_fxval _fast& )\
DECL_ASN_OP_T( op , const sc_fxnum& )\
DECL_ASN_OP_T( op , const sc_fxnum_fast& )\
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_f ix& )
DECL_ASN_OP_T( &= , const sc_f ix_fast& )
DECL_ASN_OP_T( |= , const sc_f ix& )
DECL_ASN_OP_T( |= , const sc_f ix_fast& )
DECL_ASN_OP_T( ^= , const sc_f ix& )
DECL_ASN_OP_T( ^= , const sc_f ix_fast& )
const sc_f xval _f ast oper ator ++ ( i nt );
const sc_f xval _f ast oper ator-- ( i nt );
sc_f ix_fast& oper ator ++ ();
sc_f ix_fast& oper ator-- ();
} ;
} // namespace sc_dt
7.10.16.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
sc_fix_fast shall use double-precision (f loating-poi nt) val ues. The manti ssa of a double-preci si on val ue i s
li mi ted to 53 bits, so bi t-true behavior cannot be guaranteed wi th the li mited-precision types.
7.10.16.4 Public constructors
The constructor arguments may speci fy the fi xed-point type parameters, as descri bed in 7.10.1. The default
constructor shall set f ixed-point type parameters according to the fi xed-point context in scope at the point of
construction. An i ni ti al val ue may additional ly be speci fi ed as a C++ or SystemC numeric obj ect or as a
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


355
Copyright 2012 IEEE. All rights reserved.
string l iteral. A fi xed-point cast swi tch may also be passed as a constructor argument to set the f ixed-poi nt
casting, as described in 7.10.7.
7.10.16.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fix_fast, usi ng truncation or si gn-extensi on, as described i n 7.10.4.
7.10.16.6 Bitwise operators
Bitwi se operators for operands of type sc_fix_fast shall be defi ned, as descri bed i n 7.10.4.
7.10.17 sc_ufix_fast
7.10.17.1 Description
Cl ass sc_ufix_fast shal l represent an unsi gned li mited-precision fi xed-poi nt val ue. The f ixed-point type
parameters wl, iwl, q_mode, o_mode, and n_bitsmay be specif ied as constructor arguments.
7.10.17.2 Class definition
namespace sc_dt {
class sc_ufix_fast
: publi c sc_f xnum_f ast
{
publ ic:
// Constructors
expl icit sc_ufix_fast();
sc_ufix_fast( i nt , int );
sc_ufix_fast( sc_q_mode , sc_o_mode );
sc_ufix_fast( sc_q_mode , sc_o_mode , i nt );
sc_ufix_fast( i nt , int , sc_q_mode , sc_o_mode );
sc_ufix_fast( i nt , int , sc_q_mode , sc_o_mode , int );
expl icit sc_ufix_fast( const sc_fxcast_swi tch& );
sc_ufix_fast( i nt , int , const sc_fxcast_switch& );
sc_ufix_fast( sc_q_mode , sc_o_mode , const sc_fxcast_switch& );
sc_ufix_fast( sc_q_mode , sc_o_mode , i nt , const sc_fxcast_swi tch& );
sc_ufix_fast( i nt , int , sc_q_mode , sc_o_mode , const sc_f xcast_switch& );
sc_ufix_fast( i nt , int , sc_q_mode , sc_o_mode , i nt , const sc_fxcast_swi tch& );
expl icit sc_ufix_fast( const sc_fxtype_params& );
sc_ufix_fast( const sc_fxtype_params& , const sc_f xcast_switch& );
#def ine DECL_CTORS_T( tp ) \
sc_uf ix_fast( tp , i nt , int ); \
sc_uf ix_fast( tp , sc_q_mode , sc_o_mode ); \
sc_uf ix_fast( tp , sc_q_mode , sc_o_mode , int ); \
sc_ufi x_fast( tp , int , i nt , sc_q_mode , sc_o_mode ); \
sc_ufi x_fast( tp , int , i nt , sc_q_mode , sc_o_mode , int ); \
sc_ufi x_fast( tp , const sc_f xcast_switch& ); \
sc_ufi x_f ast( tp , int , i nt , const sc_f xcast_swi tch& ); \
sc_ufi x_f ast( tp , sc_q_mode , sc_o_mode , const sc_fxcast_swi tch& ); \
sc_ufi x_f ast( tp , sc_q_mode , sc_o_mode , int , const sc_f xcast_switch& ); \
sc_ufi x_f ast( tp , int , i nt , sc_q_mode , sc_o_mode , const sc_fxcast_swi tch& ); \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


356
Copyright 2012 IEEE. All rights reserved.
sc_ufi x_fast( tp , int , i nt , sc_q_mode , sc_o_mode , int , const sc_fxcast_switch& ); \
sc_ufi x_fast( tp , const sc_f xtype_params& ); \
sc_ufi x_fast( tp , const sc_f xtype_params& , const sc_fxcast_switch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_uf ix_fast( tp ); \
DECL_CTORS_T( tp )
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_ufix_f ast( tp ); \
DECL_CTORS_T( tp )
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
#undef DECL_CTORS_T
#undef DECL_CTORS_T_A
#undef DECL_CTORS_T_B
// Copy constructor
sc_ufix_fast( const sc_ufix_f ast& );
// Unary bi twi se operators
const sc_uf ix_fast oper ator ~ () const;
// Binary bitwise operators
f riend const sc_ufi x_f ast oper ator & ( const sc_uf ix_fast& , const sc_uf ix_fast& );
f riend const sc_ufi x_f ast oper ator ^ ( const sc_uf ix_f ast& , const sc_uf ix_fast& );
f riend const sc_ufi x_f ast oper ator | ( const sc_uf ix_f ast& , const sc_ufi x_f ast& );
// Assi gnment operators
sc_ufi x_f ast& oper ator = ( const sc_uf ix_f ast& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_ufi x_f ast& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& )\
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


357
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int )\
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* )\
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_uf ix& )
DECL_ASN_OP_T( &= , const sc_uf ix_fast& )
DECL_ASN_OP_T( |= , const sc_ufi x& )
DECL_ASN_OP_T( |= , const sc_uf ix_fast& )
DECL_ASN_OP_T( ^= , const sc_uf ix& )
DECL_ASN_OP_T( ^= , const sc_uf ix_fast& )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval _f ast oper ator ++ ( i nt );
const sc_f xval _f ast oper ator-- ( i nt );
sc_ufi x_f ast& oper ator ++ ();
sc_ufi x_f ast& oper ator-- ();
} ;
} // namespace sc_dt
7.10.17.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
sc_ufix_fast shall use double-preci si on (f loating-poi nt) val ues. The mantissa of a double-preci si on val ue is
li mi ted to 53 bits, so bi t-true behavior cannot be guaranteed wi th the li mited-precision types.
7.10.17.4 Public constructors
The constructor arguments may speci fy the fi xed-point type parameters, as descri bed in 7.10.1. The default
constructor shall set f ixed-point type parameters according to the fi xed-point context in scope at the point of
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


358
Copyright 2012 IEEE. All rights reserved.
construction. An i ni ti al val ue may additional ly be speci fi ed as a C++ or SystemC numeric obj ect or as a
string l iteral. A fi xed-point cast swi tch may also be passed as a constructor argument to set the f ixed-poi nt
casting, as described in 7.10.7.
7.10.17.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_ufix_fast, usi ng truncation or si gn-extensi on, as descri bed in 7.10.4.
7.10.17.6 Bitwise operators
Bitwi se operators for operands of type sc_ufix_fast shal l be defi ned, as descri bed in 7.10.4.
7.10.18 sc_fixed
7.10.18.1 Description
Class template sc_fixed shall represent a signed (twos complement) fi ni te-preci si on fi xed-poi nt value. The
f ixed-poi nt type parameters wl, iwl, q_mode, o_mode, and n_bits shal l be specif ied by the template
arguments.
Any publi c member f unctions of the base cl ass sc_fix that are overridden in cl ass sc_fixed shal l have the
same behavior in the two cl asses. Any publ ic member f uncti ons of the base class not overridden i n this way
shall be publi cl y i nherited by cl ass sc_fixed.
7.10.18.2 Class definition
namespace sc_dt {
templ ate <i nt W, i nt I,
sc_q_mode Q = SC_DEFAULT_Q_MODE_,
sc_o_mode O = SC_DEFAULT_O_MODE_, int N = SC_DEFAULT_N_BI TS_>
class sc_fixed
: publi c sc_f ix
{
publ ic:
// Constructors
sc_fixed();
sc_fixed( const sc_fxcast_swi tch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_f ixed( tp ); \
sc_f ixed( tp , const sc_f xcast_swi tch& );
#def ine DECL_CTORS_T_B( tp ) \
sc_f ixed( tp ); \
sc_f ixed( tp , const sc_f xcast_swi tch& );
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


359
Copyright 2012 IEEE. All rights reserved.
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
sc_f ixed( const sc_f ixed<W,I,Q,O,N>& );
// Operators
sc_f ixed& oper ator = ( const sc_fi xed<W,I ,Q,O,N>& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f ixed& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op, f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_f ix& )
DECL_ASN_OP_T( &= , const sc_f ix_fast& )
DECL_ASN_OP_T( |= , const sc_f ix& )
DECL_ASN_OP_T( |= , const sc_f ix_fast& )
DECL_ASN_OP_T( ^= , const sc_f ix& )
DECL_ASN_OP_T( ^= , const sc_f ix_fast& )
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


360
Copyright 2012 IEEE. All rights reserved.
sc_f ixed& oper ator ++ ();
sc_f ixed& oper ator-- ();
} ;
} // namespace sc_dt
7.10.18.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
7.10.18.4 Public constructors
The ini ti al value of an sc_fixed obj ect may be specif ied as a constructor argument, that i s, a C++ or SystemC
numeri c obj ect or a stri ng li teral. A fi xed-poi nt cast swi tch may al so be passed as a constructor argument to
set the f ixed-point casting, as descri bed in 7.10.7.
7.10.18.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fixed, usi ng truncation or si gn-extension, as descri bed in 7.10.4.
7.10.19 sc_ufixed
7.10.19.1 Description
Class templ ate sc_ufixed represents an unsi gned f ini te-precision fi xed-point value. The f ixed-point type
parameters wl, iwl, q_mode, o_mode, and n_bitsshal l be specif ied by the templ ate arguments.
Any publ ic member f unctions of the base class sc_ufix that are overri dden in class sc_ufixed shal l have the
same behavior in the two cl asses. Any publ ic member f uncti ons of the base class not overridden i n this way
shall be publi cl y i nherited by cl ass sc_ufixed.
7.10.19.2 Class definition
namespace sc_dt {
templ ate <i nt W, i nt I,
sc_q_mode Q = SC_DEFAULT_Q_MODE_,
sc_o_mode O = SC_DEFAULT_O_MODE_, int N = SC_DEFAULT_N_BITS_>
class sc_ufixed
: publi c sc_uf ix
{
publ ic:
// Constructors
expl icit sc_ufixed();
expl icit sc_ufixed( const sc_fxcast_switch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_ufi xed( tp ); \
sc_ufi xed( tp , const sc_fxcast_swi tch& );
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_ufixed( tp ); \
sc_ufi xed( tp , const sc_fxcast_swi tch& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


361
Copyright 2012 IEEE. All rights reserved.
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
#undef DECL_CTORS_T_A
#undef DECL_CTORS_T_B
// Copy constructor
sc_ufixed( const sc_ufi xed<W,I ,Q,O,N>& );
// Assi gnment operators
sc_ufi xed& oper ator = ( const sc_uf ixed<W,I ,Q,O,N>& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_ufi xed& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& )\
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int )\
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned l ong ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_f xnum_f ast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


362
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_uf ix& )
DECL_ASN_OP_T( &= , const sc_uf ix_fast& )
DECL_ASN_OP_T( |= , const sc_ufi x& )
DECL_ASN_OP_T( |= , const sc_uf ix_fast& )
DECL_ASN_OP_T( ^= , const sc_uf ix& )
DECL_ASN_OP_T( ^= , const sc_uf ix_fast& )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval oper ator ++ ( i nt );
const sc_f xval oper ator-- ( i nt );
sc_ufi xed& oper ator ++ ();
sc_ufi xed& oper ator-- ();
} ;
} // namespace sc_dt
7.10.19.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
7.10.19.4 Public constructors
The ini ti al value of an sc_ufixed obj ect may be speci fi ed as a constructor argument that i s a C++ or
SystemC numeri c object or a stri ng li teral . A fi xed-poi nt cast swi tch may al so be passed as a constructor
argument to set the fi xed-point casting, as descri bed in 7.10.7.
7.10.19.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_ufixed, usi ng truncation or si gn-extension, as descri bed in 7.10.4.
7.10.20 sc_fixed_fast
7.10.20.1 Description
Class templ ate sc_fixed_fast shall represent a signed (twos complement) limited-precision fixed-point
type. The fi xed-poi nt type parameters wl, iwl, q_mode, o_mode, and n_bits shal l be speci fi ed by the
templ ate arguments.
Any publ ic member functi ons of the base cl ass sc_fix_fast that are overridden in class sc_fixed_fast shal l
have the same behavior in the two cl asses. Any publ ic member f unctions of the base cl ass not overri dden in
thi s way shall be publ icly i nheri ted by class sc_fixed_fast.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


363
Copyright 2012 IEEE. All rights reserved.
7.10.20.2 Class definition
namespace sc_dt {
templ ate <i nt W, i nt I,
sc_q_mode Q = SC_DEFAULT_Q_MODE_,
sc_o_mode O = SC_DEFAULT_O_MODE_, int N = SC_DEFAULT_N_BI TS_>
class sc_fixed_fast
: publi c sc_f ix_fast
{
publ ic:
// Constructors
sc_fixed_fast();
sc_fixed_fast( const sc_fxcast_swi tch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_f ixed_f ast( tp ); \
sc_f ixed_f ast( tp , const sc_f xcast_switch& );
#def ine DECL_CTORS_T_B( tp ) \
sc_f ixed_f ast( tp ); \
sc_f ixed_f ast( tp , const sc_f xcast_switch& );
DECL_CTORS_T_A( int )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( long )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _f ast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_f xnum_f ast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsi gned& )
sc_fi xed_f ast( const sc_f ixed_f ast<W,I,Q,O,N>& );
// Operators
sc_f ixed_f ast& oper ator = ( const
sc_f ixed_f ast<W,I ,Q,O,N>& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_f ixed_f ast& operator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


364
Copyright 2012 IEEE. All rights reserved.
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int ) \
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned long ) \
DECL_ASN_OP_T( op , f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* ) \
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& ) \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_f ix& )
DECL_ASN_OP_T( &= , const sc_f ix_fast& )
DECL_ASN_OP_T( |= , const sc_f ix& )
DECL_ASN_OP_T( |= , const sc_f ix_fast& )
DECL_ASN_OP_T( ^= , const sc_f ix& )
DECL_ASN_OP_T( ^= , const sc_f ix_fast& )
const sc_f xval _f ast oper ator ++ ( i nt );
const sc_f xval _f ast oper ator-- ( i nt );
sc_f ixed_f ast& oper ator ++ ();
sc_f ixed_f ast& oper ator-- ();
} ;
} // namespace sc_dt
7.10.20.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
sc_fixed_fast shall use double-preci si on (fl oating-point) values whose mantissa is li mited to 53 bits.
7.10.20.4 Public constructors
The i nitial value of an sc_fixed_fast object may be specif ied as a constructor argument that is a C++ or
SystemC numeri c object or a stri ng li teral . A fi xed-poi nt cast swi tch may al so be passed as a constructor
argument to set the fi xed-point casting, as descri bed in 7.10.7.
7.10.20.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fixed_fast, usi ng truncati on or si gn-extensi on, as descri bed in 7.10.4.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


365
Copyright 2012 IEEE. All rights reserved.
7.10.21 sc_ufixed_fast
7.10.21.1 Description
Class templ ate sc_ufixed_fast shall represent an unsigned li mited-precision f ixed-point type. The f ixed-
point type parameters wl, iwl, q_mode, o_mode, and n_bitsshall be specif ied by the templ ate arguments.
Any publi c member f unctions of the base cl ass sc_ufix_fast that are overri dden i n class sc_ufixed_fast shall
have the same behavior in the two cl asses. Any publ ic member f unctions of the base cl ass not overri dden in
thi s way shall be publ icly i nheri ted by class sc_ufixed_fast.
7.10.21.2 Class definition
namespace sc_dt {
templ ate <i nt W, i nt I,
sc_q_mode Q = SC_DEFAULT_Q_MODE_,
sc_o_mode O = SC_DEFAULT_O_MODE_, int N = SC_DEFAULT_N_BITS_>
class sc_ufixed_fast
: publi c sc_uf ix_fast
{
publ ic:
// Constructors
expl icit sc_ufixed_fast();
expl icit sc_ufixed_fast( const sc_fxcast_swi tch& );
#def ine DECL_CTORS_T_A( tp ) \
sc_ufi xed_fast( tp ); \
sc_ufi xed_fast( tp , const sc_fxcast_swi tch& );
#def ine DECL_CTORS_T_B( tp ) \
expl icit sc_ufi xed_fast ( tp );\
sc_ufi xed_fast( tp , const sc_fxcast_swi tch& );
DECL_CTORS_T_A( i nt )
DECL_CTORS_T_A( unsi gned int )
DECL_CTORS_T_A( l ong )
DECL_CTORS_T_A( unsi gned long )
DECL_CTORS_T_A( fl oat )
DECL_CTORS_T_A( doubl e )
DECL_CTORS_T_A( const char* )
DECL_CTORS_T_A( const sc_f xval & )
DECL_CTORS_T_A( const sc_f xval _fast& )
DECL_CTORS_T_A( const sc_f xnum& )
DECL_CTORS_T_A( const sc_fxnum_fast& )
DECL_CTORS_T_B( int64 )
DECL_CTORS_T_B( uint64 )
DECL_CTORS_T_B( const sc_i nt_base& )
DECL_CTORS_T_B( const sc_ui nt_base& )
DECL_CTORS_T_B( const sc_signed& )
DECL_CTORS_T_B( const sc_unsigned& )
#undef DECL_CTORS_T_A
#undef DECL_CTORS_T_B
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


366
Copyright 2012 IEEE. All rights reserved.
// Copy constructor
sc_ufixed_fast( const sc_ufi xed_fast<W,I ,Q,O,N>& );
// Assi gnment operators
sc_ufi xed_fast& oper ator = ( const sc_uf ixed_fast<W,I,Q,O,N>& );
#def ine DECL_ASN_OP_T( op , tp ) \
sc_ufi xed_fast& oper ator op ( tp );
#def ine DECL _ASN_OP_OT HER( op ) \
DECL_ASN_OP_T( op , i nt64 ) \
DECL_ASN_OP_T( op , ui nt64 ) \
DECL_ASN_OP_T( op , const sc_int_base& ) \
DECL_ASN_OP_T( op , const sc_uint_base& ) \
DECL_ASN_OP_T( op , const sc_si gned& ) \
DECL_ASN_OP_T( op , const sc_unsigned& )
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , i nt ) \
DECL_ASN_OP_T( op , unsi gned int )\
DECL_ASN_OP_T( op , l ong ) \
DECL_ASN_OP_T( op , unsigned l ong ) \
DECL_ASN_OP_T( op, f loat ) \
DECL_ASN_OP_T( op , double ) \
DECL_ASN_OP_T( op , const char* )\
DECL_ASN_OP_T( op , const sc_fxval& ) \
DECL_ASN_OP_T( op , const sc_fxval _fast& ) \
DECL_ASN_OP_T( op , const sc_fxnum& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast& \
DECL_ASN_OP_OTHER( op )
DECL_ASN_OP( = )
DECL_ASN_OP( * = )
DECL_ASN_OP( /= )
DECL_ASN_OP( += )
DECL_ASN_OP( -= )
DECL_ASN_OP_T( <<= , int )
DECL_ASN_OP_T( >>= , int )
DECL_ASN_OP_T( &= , const sc_uf ix& )
DECL_ASN_OP_T( &= , const sc_uf ix_fast& )
DECL_ASN_OP_T( |= , const sc_ufi x& )
DECL_ASN_OP_T( |= , const sc_uf ix_fast& )
DECL_ASN_OP_T( ^= , const sc_uf ix& )
DECL_ASN_OP_T( ^= , const sc_uf ix_fast& )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP_OTHER
#undef DECL_ASN_OP
// Auto-increment and auto-decrement
const sc_f xval _f ast oper ator ++ ( i nt );
const sc_f xval _f ast oper ator-- ( i nt );
sc_ufi xed_fast& oper ator ++ ();
sc_ufi xed_fast& oper ator-- ();
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


367
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_dt
7.10.21.3 Constraints on usage
The word length shal l be greater than zero. The number of saturated bi ts, if speci fi ed, shall not be l ess than
zero.
sc_ufixed_fast shall use doubl e-preci si on (fl oating-point) val ues whose manti ssa i s l imited to 53 bi ts.
7.10.21.4 Public constructors
The initial val ue of an sc_fixed_fast object may be specifi ed as a constructor argument, that is, a C++ or
SystemC numeri c object or a stri ng li teral . A fi xed-poi nt cast swi tch may al so be passed as a constructor
argument to set the fi xed-point casting, as descri bed in 7.10.7.
7.10.21.5 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
numeri c representation to sc_fixed_fast, usi ng truncati on or si gn-extensi on, as descri bed in 7.10.4.
7.10.22 Bit-selects
7.10.22.1 Description
Cl ass sc_fxnum_bi tref

shall represent a bit sel ected from an sc_fxnum.


Cl ass sc_fxnum_fast_bi tref

shall represent a bit sel ected from an sc_fxnum_fast.


No disti nction shal l be made between a bit-select used as an lval ue or as an rval ue.
7.10.22.2 Class definition
namespace sc_dt {
class sc_fxnum_bi tr ef

{
f riend cl ass sc_fxnum;
f ri end cl ass sc_fxnum_fast_bi tref

;
publ ic:
// Copy constructor
sc_fxnum_bi tr ef

( const sc_fxnum_bi tr ef

& );
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) \
sc_fxnum_bi tr ef

& operator op ( tp );
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , const sc_fxnum_bi tref

& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast_bi tref

& ) \
DECL_ASN_OP_T( op , bool )
DECL_ASN_OP( = )
DECL_ASN_OP( & = )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


368
Copyright 2012 IEEE. All rights reserved.
DECL_ASN_OP( |= )
DECL_ASN_OP( ^= )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP
// Impl icit conversion
oper ator bool() const;
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
// Constructors
sc_fxnum_bi tr ef

( sc_fxnum& , int );
sc_fxnum_bi tr ef

();
} ;
// -------------------------------------------------------------
class sc_fxnum_fast_bi tref

{
f riend cl ass sc_fxnum_fast;
f ri end cl ass sc_fxnum_bi tr ef

;
publ ic:
// Copy constructor
sc_fxnum_fast_bi tref

( const sc_fxnum_fast_bi tr ef

& );
// Assi gnment operators
#def ine DECL_ASN_OP_T( op , tp ) \
sc_fxnum_fast_bi tref

& operator op ( tp );
#def ine DECL_ASN_OP( op ) \
DECL_ASN_OP_T( op , const sc_fxnum_bi tref

& ) \
DECL_ASN_OP_T( op , const sc_fxnum_fast_bi tref

& ) \
DECL_ASN_OP_T( op , bool )
DECL_ASN_OP( = )
DECL_ASN_OP( & = )
DECL_ASN_OP( |= )
DECL_ASN_OP( ^= )
#undef DECL_ASN_OP_T
#undef DECL_ASN_OP
// Impl icit conversion
oper ator bool() const;
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


369
Copyright 2012 IEEE. All rights reserved.
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
// Constructor
sc_fxnum_fast_bi tref

( sc_fxnum_f ast& , i nt );
sc_fxnum_fast_bi tref

();
} ;
} // namespace sc_dt
7.10.22.3 Constraints on usage
Bit-select obj ects shal l only be created using the bi t-select operators of an i nstance of a class derived f rom
sc_fxnum or sc_fxnum_fast.
An appl ication shall not expli citl y create an i nstance of any bi t-sel ect class.
An appl ication should not decl are a reference or pointer to any bit-sel ect obj ect.
7.10.22.4 Assignment operators
Overl oaded assi gnment operators shall provide conversi on f rom bool val ues.
7.10.22.5 Implicit type conversion
oper ator bool() const;
Operator bool can be used for i mpli ci t type conversi on from a bi t-sel ect to the native C++ bool
representation.
7.10.23 Part-selects
7.10.23.1 Description
Cl ass sc_fxnum_subr ef

shall represent a part-sel ect from an sc_fx_num.


Cl ass sc_fxnum_fast_subr ef

shall represent a part-sel ect from an sc_fxnum_fast.


No disti nction shall be made between a part-select used as an l val ue or as an rvalue.
7.10.23.2 Class definition
namespace sc_dt {
class sc_fxnum_subr ef

{
f riend cl ass sc_fxnum;
f ri end cl ass sc_fxnum_fast_subr ef

;
publ ic:
// Copy constructor
sc_fxnum_subr ef

( const sc_fxnum_subr ef

& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


370
Copyright 2012 IEEE. All rights reserved.
// Destructor
~sc_fxnum_subr ef

();
// Assi gnment operators
#def ine DECL_ASN_OP_T( tp ) \
sc_fxnum_subr ef

& oper ator = ( tp );


DECL_ASN_OP_T( const sc_fxnum_subr ef

& )
DECL_ASN_OP_T( const sc_fxnum_fast_subr ef

& )
DECL_ASN_OP_T( const sc_bv_base& )
DECL_ASN_OP_T( const sc_l v_base& )
DECL_ASN_OP_T( const char* )
DECL_ASN_OP_T( const bool* )
DECL_ASN_OP_T( const sc_signed& )
DECL_ASN_OP_T( const sc_unsigned& )
DECL_ASN_OP_T( const sc_i nt_base& )
DECL_ASN_OP_T( const sc_ui nt_base& )
DECL_ASN_OP_T( int64 )
DECL_ASN_OP_T( uint64 )
DECL_ASN_OP_T( i nt )
DECL_ASN_OP_T( unsi gned int )
DECL_ASN_OP_T( long )
DECL_ASN_OP_T( unsi gned long )
DECL_ASN_OP_T( char )
#undef DECL_ASN_OP_T
#def ine DECL_ASN_OP_T_A( op , tp ) \
sc_fxnum_subr ef

& operator op ## = ( tp );
#def ine DECL_ASN_OP_A( op ) \
DECL_ASN_OP_T_A( op , const sc_fxnum_subr ef

& ) \
DECL_ASN_OP_T_A( op , const sc_fxnum_fast_subr ef

& ) \
DECL_ASN_OP_T_A( op , const sc_bv_base& ) \
DECL_ASN_OP_T_A( op , const sc_l v_base& )
DECL_ASN_OP_A( & )
DECL_ASN_OP_A( | )
DECL_ASN_OP_A( ^ )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


371
Copyright 2012 IEEE. All rights reserved.
#undef DECL_ASN_OP_T_A
#undef DECL_ASN_OP_A
// Relati onal operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxnum_subr ef

& , tp ); \
f riend bool operator op ( tp , const sc_fxnum_subr ef

& );
#def ine DECL_REL _OP( op ) \
f riend bool operator op ( const sc_fxnum_subr ef

& , const sc_fxnum_subr ef

& ); \
f riend bool operator op ( const sc_fxnum_subr ef

& , const sc_fxnum_fast_subr ef

& ); \
DECL_REL_OP_T( op , const sc_bv_base& ) \
DECL_REL_OP_T( op , const sc_l v_base& ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_T( op , const bool* ) \
DECL_REL_OP_T( op , const sc_signed& ) \
DECL_REL_OP_T( op , const sc_unsi gned& ) \
DECL_REL_OP_T( op , i nt ) \
DECL_REL_OP_T( op , unsi gned int ) \
DECL_REL_OP_T( op , l ong ) \
DECL_REL_OP_T( op , unsi gned long )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
#undef DECL_REL_OP_T
#undef DECL_REL_OP
// Reduce f unctions
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Query parameter
int length() const;
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Impl icit conversion
operator sc_bv_base() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


372
Copyright 2012 IEEE. All rights reserved.
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
// Constructor
sc_fxnum_subr ef

( sc_fxnum& , int , i nt );
sc_fxnum_subr ef

();
} ;
// -------------------------------------------------------------
class sc_fxnum_fast_subr ef

{
f riend cl ass sc_fxnum_fast;
f ri end cl ass sc_fxnum_subr ef

;
publ ic:
// Copy constructor
sc_fxnum_fast_subr ef

( const sc_fxnum_fast_subr ef

& );
// Destructor
~sc_fxnum_fast_subr ef

();
// Assi gnment operators
#def ine DECL_ASN_OP_T( tp ) \
sc_fxnum_fast_subr ef

& operator= ( tp );
DECL_ASN_OP_T( const sc_fxnum_subr ef

& )
DECL_ASN_OP_T( const sc_fxnum_fast_subr ef

& )
DECL_ASN_OP_T( const sc_bv_base& )
DECL_ASN_OP_T( const sc_l v_base& )
DECL_ASN_OP_T( const char* )
DECL_ASN_OP_T( const bool* )
DECL_ASN_OP_T( const sc_signed& )
DECL_ASN_OP_T( ( const sc_unsigned& )
DECL_ASN_OP_T( const sc_i nt_base& )
DECL_ASN_OP_T( const sc_ui nt_base& )
DECL_ASN_OP_T( int64 )
DECL_ASN_OP_T( uint64 )
DECL_ASN_OP_T( i nt )
DECL_ASN_OP_T( unsi gned int )
DECL_ASN_OP_T( long )
DECL_ASN_OP_T( unsi gned long )
DECL_ASN_OP_T( char )
#undef DECL_ASN_OP_T
#def ine DECL_ASN_OP_T_A( op , tp ) \
sc_f xnum_f ast_subref& operator op ## = ( tp );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


373
Copyright 2012 IEEE. All rights reserved.
#def ine DECL_ASN_OP_A( op ) \
DECL_ASN_OP_T_A( op , const sc_fxnum_subr ef

& ) \
DECL_ASN_OP_T_A( op , const sc_fxnum_fast_subr ef

& ) \
DECL_ASN_OP_T_A( op , const sc_bv_base& ) \
DECL_ASN_OP_T_A( op , const sc_l v_base& )
DECL_ASN_OP_A( & )
DECL_ASN_OP_A( | )
DECL_ASN_OP_A( ^ )
#undef DECL_ASN_OP_T_A
#undef DECL_ASN_OP_A
// Relati onal operators
#def ine DECL_REL _OP_T( op , tp ) \
f riend bool operator op ( const sc_fxnum_fast_subr ef

& , tp ); \
f riend bool operator op ( tp , const sc_fxnum_fast_subr ef

& );
#def ine DECL_REL _OP( op ) \
f riend bool operator op ( const sc_fxnum_fast_subr ef

& , const sc_fxnum_fast_subr ef

& ); \
f riend bool operator op ( const sc_fxnum_fast_subr ef

& , const sc_fxnum_subr ef

& ); \
DECL_REL_OP_T( op , const sc_bv_base& ) \
DECL_REL_OP_T( op , const sc_l v_base& ) \
DECL_REL_OP_T( op , const char* ) \
DECL_REL_OP_T( op , const bool* ) \
DECL_REL_OP_T( op , const sc_signed& ) \
DECL_REL_OP_T( op , const sc_unsi gned& ) \
DECL_REL_OP_T( op , i nt ) \
DECL_REL_OP_T( op , unsi gned int ) \
DECL_REL_OP_T( op , l ong ) \
DECL_REL_OP_T( op , unsi gned long )
DECL_REL_OP( == )
DECL_REL_OP( ! = )
#undef DECL_REL_OP_T
#undef DECL_REL_OP
// Reduce f unctions
bool and_r educe() const;
bool nand_r educe() const;
bool or_r educe() const;
bool nor_reduce() const;
bool xor_reduce() const;
bool xnor _reduce() const;
// Query parameter
int length() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


374
Copyright 2012 IEEE. All rights reserved.
// Expl icit conversions
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
// Impl icit conversion
operator sc_bv_base() const;
// Pri nt or dump content
void pr int( std::ostream& = std::cout ) const;
void scan( std::i stream& = std::cin );
void dump( std::ostream& = std::cout ) const;
pri vate:
// Di sabl ed
// Constructor
sc_fxnum_fast_subr ef

( sc_fxnum_fast& , int , i nt );
sc_fxnum_fast_subr ef

();
} ;
} // namespace sc_dt
7.10.23.3 Constraints on usage
Fixed-point part-sel ect objects shal l onl y be created usi ng the part-sel ect operators of an instance of a cl ass
derived from sc_fxnum or sc_fxnum_fast.
An appl ication shall not expli citl y create an instance of any fixed-point part-select class.
An appl ication should not declare a ref erence or poi nter to any fi xed-point part-select object.
No ari thmeti c operators are provided f or f ixed-poi nt part-sel ects.
7.10.23.4 Assignment operators
Overl oaded assi gnment operators shall provide conversion f rom SystemC data types and the nati ve C++
integer representation to f ixed-point part-sel ects. If the si ze of a data type or string l iteral operand di ff ers
f rom the f ixed-point part-sel ect word l ength, truncati on, zero-extensi on, or sign-extensi on shal l be used, as
descri bed in 7.2.1.
7.10.23.5 Bitwise operators
Overl oaded bi twi se operators shal l be provided for f ixed-point part-select, bit-vector, and l ogi c-vector
operands.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


375
Copyright 2012 IEEE. All rights reserved.
7.10.23.6 Implicit type conversion
sc_fxnum_subr ef

:: oper ator sc_bv_base() const;


sc_fxnum_fast_subr ef

:: oper ator sc_bv_base() const;


Operator sc_bv_base can be used for impl icit type conversion from integer part-sel ects to the
SystemC bi t-vector representation.
7.10.23.7 Explicit type conversion
int to_int() const;
unsi gned int to_uint() const;
long to_long() const;
unsi gned long to_ulong() const;
int64 to_int64() const;
uint64 to_uint64() const;
These member functions shall perf orm the conversi on to C++ i nteger types.
const std::string to_str ing() const;
const std::string to_str ing( sc_numrep ) const;
const std::string to_str ing( sc_numrep , bool ) const;
Member f uncti on to_str ing shall perf orm the conversi on to a str ing representati on, as descri bed i n
7.2.11, 7.10.8, and 7.10.8.1.
7.11 Contexts
This subclause descri bes the cl asses that are provided to set the contexts for the data types.
7.11.1 sc_length_param
7.11.1.1 Description
Cl ass sc_length_param shal l represent a l ength parameter and shal l be used to create a l ength context, as
descri bed in 7.2.3.
7.11.1.2 Class definition
namespace sc_dt {
class sc_length_par am
{
publ ic:
sc_length_param();
sc_length_param( i nt );
sc_length_param( const sc_length_param& );
sc_length_param& oper ator = ( const sc_length_param& );
f riend bool oper ator == ( const sc_length_param& , const sc_length_param& );
f riend bool oper ator != ( const sc_length_param& , const sc_length_param& );
int len() const;
void len( i nt );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


376
Copyright 2012 IEEE. All rights reserved.
const std::string to_str ing() const;
void pr int( std::ostream& = std::cout ) const;
void dump( std::ostream& = std::cout ) const;
} ;
} // namespace sc_dt
7.11.1.3 Constraints on usage
The l ength (where speci fi ed) shal l be greater than zero.
7.11.1.4 Public constructors
sc_length_param();
Default constructor sc_length_par am shall create an sc_length_param obj ect wi th the default
word l ength of 32.
sc_length_param( i nt n ) ;
Constructor sc_length_par am shal l create an sc_length_param wi th n as the word length with n >
0.
sc_length_param( const sc_length_param& );
Constructor sc_length_par am shall create a copy of the object given as its argument.
7.11.1.5 Public methods
int len() const;
Member f uncti on len shall return the word l ength stored i n the sc_length_param.
void len( i nt n );
Member f uncti on l en shal l set the word length of the sc_length_par am to n, with n > 0.
const std::string to_str ing() const;
Member f uncti on to_str ing shall convert the sc_length_param into i ts stri ng representation.
void pr int( std::ostream& = std::cout ) const;
Member f uncti on pr int shall pri nt the contents to a stream.
7.11.1.6 Public operators
sc_length_param& oper ator = ( const sc_length_param& a );
oper ator = shall assign the word-l ength value of a to the lef t-hand si de sc_length_par am instance.
f riend bool oper ator == ( const sc_length_param& a , sc_length_param& b );
oper ator == shall return true if the stored l engths of a and b are equal.
f riend bool oper ator != ( const sc_length_param& a , const sc_l ength_param& b );
oper ator != shal l return true if the stored lengths of a and b are not equal.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


377
Copyright 2012 IEEE. All rights reserved.
7.11.2 sc_length_context
7.11.2.1 Description
Cl ass sc_length_context shal l be used to create a length context for SystemC i nteger and vector obj ects.
7.11.2.2 Class definition
namespace sc_dt {
class sc_length_context
{
publ ic:
expl icit sc_length_context( const sc_length_param& , sc_context_begi n

= SC_NOW );
~sc_length_context();
void begin();
void end();
stati c const sc_length_param& default_value();
const sc_l ength_param& value() const;
} ;
} // namespace sc_dt
7.11.2.3 Public constructor
expl icit sc_length_context( const sc_length_param& , sc_context_begi n

= SC_NOW );
Constructor sc_length_context shall create an sc_length_context obj ect. The fi rst argument shall
be the length parameter to use. The second argument, if suppl ied, shall have the value SC_NOW or
SC_LATER.
7.11.2.4 Public member functions
void begin();
Member f uncti on begin shal l set the current length context, as descri bed i n 7.2.3.
stati c const sc_l ength_param& default_value();
Member f uncti on default_value shall return the l ength parameter currently in context.
void end();
Member f unction end shal l deacti vate the length context and shall remove it from the top of the
length context stack, as described in 7.2.3.
const sc_l ength_param& value() const;
Member f uncti on value shall return the l ength parameter.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


378
Copyright 2012 IEEE. All rights reserved.
7.11.3 sc_fxtype_params
7.11.3.1 Description
Cl ass sc_fxtype_par ams shall represent a length parameter and shal l be used to create a l ength context for
f ixed-poi nt objects, as described i n 7.2.3.
7.11.3.2 Class definition
namespace sc_dt {
class sc_fxtype_par ams
{
publ ic:
// Constructors and destructor
sc_fxtype_par ams();
sc_fxtype_par ams( i nt , int );
sc_fxtype_par ams( sc_q_mode , sc_o_mode, i nt = 0 );
sc_fxtype_par ams( i nt , int , sc_q_mode , sc_o_mode , i nt = 0 );
sc_fxtype_par ams( const sc_fxtype_params& );
sc_fxtype_par ams( const sc_fxtype_params& , int , int );
sc_fxtype_par ams( const sc_fxtype_params& , sc_q_mode , sc_o_mode , int = 0 );
// Operators
sc_f xtype_params& oper ator = ( const sc_fxtype_params& );
f riend bool oper ator == ( const sc_fxtype_params& , const sc_f xtype_params& );
f riend bool oper ator != ( const sc_fxtype_params& , const sc_f xtype_params& );
// Methods
int wl() const;
void wl( i nt );
int iwl() const;
void iwl( i nt );
sc_q_mode q_mode() const;
void q_mode( sc_q_mode );
sc_o_mode o_mode() const;
void o_mode( sc_o_mode );
int n_bits() const;
void n_bits( i nt );
const std::string to_str ing() const;
void pr int( std::ostream& = std::cout ) const;
void dump( std::ostream& = std::cout ) const;
} ;
} // namespace sc_dt
7.11.3.3 Constraints on usage
The l ength (where speci fi ed) shal l be greater than zero.
7.11.3.4 Public constructors
sc_fxtype_par ams( i nt wl , i nt iwl ) ;
sc_fxtype_par ams( sc_q_mode q_mode , sc_o_mode o_mode ) ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


379
Copyright 2012 IEEE. All rights reserved.
sc_fxtype_par ams( sc_q_mode q_mode , sc_o_mode o_mode , i nt n_bi ts ) ;
sc_fxtype_par ams( i nt wl , i nt iwl , sc_q_mode q_mode , sc_o_mode o_mode , i nt n_bi ts ) ;
sc_fxtype_par ams( i nt wl , i nt iwl , sc_q_mode q_mode , sc_o_mode o_mode ) ;
sc_fxtype_par ams() ;
Constructor sc_fxtype_par amsshall create an sc_fxtype_paramsobject.
wl shal l be the total number of bits i n the f ixed-poi nt f ormat. wl shal l be greater than zero. The
def aul t value for wl shall be obtained from the f ixed-point context currently in scope.
iwl shall be the number of i nteger bi ts in the f ixed-poi nt format. iwl may be positive or negati ve. The
def aul t value for iwl shall be obtained from the f ixed-point context currentl y in scope.
q_mode shall be the quanti zati on mode to use. Val id values for o_mode are given in 7.10.9.9. The
def aul t value for q_mode shall be obtained from the f ixed-point context currentl y i n scope.
o_mode shal l be the overf low mode to use. Val id values for o_mode are gi ven i n 7.10.9.1. The
def aul t value for o_mode shal l be obtai ned from the fi xed-point context currently in scope.
n_bits shall be the number of saturated bits parameter for the selected overfl ow mode. n_bitsshall
be greater than or equal to zero. I f the overfl ow mode is specif ied, the default val ue shal l be zero. If
the overf low mode is not speci fi ed, the def aul t val ue shal l be obtai ned f rom the f ixed-point context
currentl y in scope.
I f no f ixed-poi nt context i s currently i n scope, the def aul t values f or wl, iwl, q_mode, o_mode, and
n_bitsshall be those def ined i n Table 38 (see 7.10.7).
7.11.3.5 Public member functions
int iwl() const;
Member f uncti on iwl shall return the i wl value.
void iwl( i nt val );
Member f uncti on iwl shal l set the i wl value to val.
int n_bits() const;
Member f uncti on n_bitsshall return the n_bitsval ue.
void n_bits( i nt );
Member f uncti on n_bitsshall set the n_bitsval ue to val.
sc_o_mode o_mode() const;
Member f uncti on o_mode shal l return the o_mode.
void o_mode( sc_o_mode mode );
Member f uncti on o_mode shal l set the o_mode to mode.
sc_q_mode q_mode() const;
Member f uncti on q_mode shall return the q_mode.
void q_mode( sc_q_mode mode );
Member f uncti on q_mode shall set the q_mode to mode.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


380
Copyright 2012 IEEE. All rights reserved.
int wl() const;
Member f uncti on wl shall return the wl val ue.
void wl( i nt val );
Member f uncti on wl shall set the wl val ue to val.
7.11.3.6 Operators
sc_fxtype_params& oper ator = ( const sc_fxtype_params& param_ );
oper ator = shal l assign the wl, iwl, q_mode, o_mode, and n_bits of param_ of the right-hand side
to the lef t-hand si de.
f riend bool oper ator == ( const sc_fxtype_params& param_a , const sc_fxtype_params& param_b );
oper ator == shall return true i f wl, iwl, q_mode, o_mode, and n_bitsof param_a are equal to the
corresponding val ues of param_b; otherwise, i t shal l return false.
f riend bool oper ator != ( const sc_fxtype_params& , const sc_f xtype_params& );
oper ator != shall return true if wl, iwl, q_mode, o_mode, and n_bits of param_a are not equal to
the corresponding val ues of param_b; otherwise, i t shall return false.
7.11.4 sc_fxtype_context
7.11.4.1 Description
Cl ass sc_fxtype_context shall be used to create a length context for f ixed-point objects.
7.11.4.2 Class definition
namespace sc_dt {
class sc_fxtype_context
{
publ ic:
expl icit sc_fxtype_context( const sc_fxtype_params& , sc_context_begi n

= SC_NOW );
~sc_fxtype_context();
void begin();
void end();
stati c const sc_f xtype_params& default_value();
const sc_f xtype_params& value() const;
} ;
} // namespace sc_dt
7.11.4.3 Public constructor
expl icit sc_fxtype_context( const sc_fxtype_params& , sc_context_begi n

= SC_NOW );
Constructor sc_fxtype_context shal l create an sc_fxtype_context obj ect. The fi rst argument shall
be the f ixed-point length parameter to use. The second argument (if suppl ied) shall have the val ue
SC_NOW or SC_LATER.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


381
Copyright 2012 IEEE. All rights reserved.
7.11.4.4 Public member functions
void begin();
Member f uncti on begin shal l set the current length context, as descri bed i n 7.2.3.
stati c const sc_f xtype_params& default_value();
Member f uncti on default_value shall return the l ength parameter currently in context.
void end();
Member function end shal l deactivate the l ength context and remove i t from the top of the l ength
context stack, as descri bed i n 7.2.3.
const sc_f xtype_params& value() const;
Member f uncti on value shall return the l ength parameter.
7.11.5 sc_fxcast_switch
7.11.5.1 Description
Cl ass sc_fxcast_switch shal l be used to set the fl oating-point cast context, as described i n 7.10.7.
7.11.5.2 Class definition
namespace sc_dt {
class sc_fxcast_switch
{
publ ic:
// Constructors
sc_fxcast_switch();
sc_fxcast_switch( sc_swi tch

);
sc_fxcast_switch( const sc_fxcast_swi tch& );
// Operators
sc_f xcast_swi tch& oper ator = ( const sc_fxcast_swi tch& );
f riend bool oper ator == ( const sc_fxcast_swi tch& , const sc_fxcast_swi tch& );
f riend bool oper ator != ( const sc_fxcast_switch& , const sc_fxcast_swi tch& );
// Methods
const std::string to_str ing() const;
void pr int( std::ostream& = std::cout ) const;
void dump( std::ostream& = std::cout ) const;
} ;
} // namespace sc_dt
7.11.5.3 Public constructors
sc_fxcast_switch ();
sc_fxcast_switch ( sc_swi tch

);
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


382
Copyright 2012 IEEE. All rights reserved.
The argument (if suppli ed) shall have the value SC_OFF or SC_ON, as descri bed in 7.10.7. The
def aul t constructor shal l use the f loating-point cast context currently i n scope.
7.11.5.4 Public member functions
void pr int( std::ostream& = std::cout ) const;
Member f uncti on pr int shal l pri nt the sc_fxcast_switch instance val ue to an output stream.
7.11.5.5 Explicit conversion
const std::string to_str ing() const;
Member function to_str ing shall return the swi tch state as the character string SC_OFF or
SC_ON.
7.11.5.6 Operators
sc_f xcast_swi tch& oper ator = ( const sc_fxtype_params& cast_swi tch );
oper ator = shall assign cast_switch to the sc_fxcast_switch on i ts lef t-hand si de.
f riend bool oper ator == (const sc_fxcast_swi tch& swi tch_a , const sc_fxcast_switch& swi tch_b ) ;
oper ator == shall return true if switch_a is equal to switch_b; otherwise, i t shal l return false.
f riend bool oper ator != ( const sc_fxcast_switch& swi tch_a , const sc_f xcast_switch& switch_b );
oper ator != shal l return true if switch_a is not equal to switch_b; otherwise, i t shal l return false.
std::ostream& oper ator << ( std::ostream& os , const sc_fxcast_swi tch& a );
oper ator << shal l pri nt the instance val ue of a to an output stream os.
7.11.6 sc_fxcast_context
7.11.6.1 Description
Cl ass sc_fxcast_context shall be used to create a f loati ng-poi nt cast context for fixed-point obj ects.
7.11.6.2 Class definition
namespace sc_dt {
class sc_fxcast_context
{
publ ic:
expl icit sc_fxcast_context( const sc_fxcast_swi tch& , sc_context_begi n

= SC_NOW );
sc_fxcast_context();
void begin();
void end();
stati c const sc_fxcast_swi tch& default_value();
const sc_f xcast_switch& value() const;
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


383
Copyright 2012 IEEE. All rights reserved.
} // namespace sc_dt
7.11.6.3 Public constructor
expl icit sc_fxcast_context( const sc_fxcast_swi tch&, sc_context_begi n

= SC_NOW );
Constructor sc_fxcast_context shall create an sc_fxcast_context obj ect. I ts fi rst argument shal l be
the floati ng-point cast switch to use. The second argument (i f suppli ed) shal l have the val ue
SC_NOW or SC_LATER.
7.11.6.4 Public member functions
void begin();
Member f uncti on begin shal l set the current fl oating-point cast context, as descri bed in 7.10.7.
stati c const sc_fxcast_swi tch& default_value();
Member f uncti on default_value shall return the cast swi tch currently in context.
void end();
Member functi on end shall deactivate the fl oating-point cast context and remove it f rom the top of
the fl oating-point cast context stack.
const sc_f xcast_switch& value() const;
Member f uncti on value shall return the cast swi tch.
7.12 Control of string representation
7.12.1 Description
Type sc_numr ep is used to control the formatting of number representati ons as character stri ngs when
passed as an argument to the to_str ing member f uncti on of a data type object.
7.12.2 Class definition
namespace sc_dt {
enum sc_numr ep
{
SC_NOBASE = 0,
SC_BIN = 2,
SC_OCT = 8,
SC_DEC = 10,
SC_HEX = 16,
SC_BIN_US,
SC_BIN_SM,
SC_OCT_US,
SC_OCT_SM,
SC_HEX_US,
SC_HEX_SM,
SC_CSD
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


384
Copyright 2012 IEEE. All rights reserved.
} ;
const std::string to_str ing( sc_numrep );
} ; // namespace sc_dt
7.12.3 Functions
const std::string to_str ing( sc_numrep );
Function to_str ing shall return a string consisti ng of the same sequence of characters as the name of
the corresponding constant value of the enumerated type sc_numr ep.
Exampl e:
to_string(SC_HEX) == "SC_HEX" // i s true
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


385
Copyright 2012 IEEE. All rights reserved.
8. SystemC utilities
8.1 Trace files
A trace f il e records a ti me-ordered sequence of value changes during simulation. The VCD trace f il e format
shall be supported.
A VCD trace f il e can onl y be created and opened by cal li ng f uncti on sc_create_vcd_tr ace_file. A trace fi le
may be opened duri ng elaborati on or at any time during simul ation. Val ues can only be traced by call ing
functi on sc_trace. A trace fi le shal l be opened bef ore values can be traced to that fi le, and values shall not be
traced to a gi ven trace f il e if one or more del ta cycl es have el apsed si nce opening the f il e. A VCD trace fi le
shall be closed by call ing f uncti on sc_close_vcd_tr ace_file. A trace f il e shall not be closed before the f inal
del ta cycl e of simul ati on.
An i mplementation may support other trace fil e formats by providing alternatives to the f uncti ons
sc_create_vcd_tr ace_file and sc_close_vcd_tr ace fi le.
The l if etime of a traced obj ect need not extend throughout the entire time the trace fi le i s open.
NOTEA trace file can be opened at any ti me, but no mechani sm i s avai l abl e to swi tch of f tracing bef ore the end of
si mul ati on.
8.1.1 Class definition and function declarations
namespace sc_core {
class sc_trace_file
{
publ ic:
virtual void set_time_unit( double , sc_ti me_unit ) = 0;
i mpl ementati on-defi ned
} ;
sc_trace_fi le* sc_create_vcd_tr ace_file( const char* name );
void sc_close_vcd_tr ace_file( sc_trace_f il e* tf );
void sc_wr ite_comment( sc_trace_f il e* tf , const std::string& comment );
void sc_trace ...
} // namespace sc_core
8.1.2 sc_trace_file
class sc_trace_file
{
publ ic:
virtual void set_time_unit( double , sc_ti me_unit ) = 0;
i mpl ementati on-defi ned
} ;
Cl ass sc_trace_file is the abstract base cl ass f rom whi ch the classes that provi de f il e handl es f or
VCD or other i mplementation-def ined trace f il e formats are derived. An appl i cation shal l not
construct obj ects of class sc_trace_file but may defi ne pointers and references to thi s type.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


386
Copyright 2012 IEEE. All rights reserved.
Member functi on set_time_unit shall be overridden in the deri ved cl ass to set the ti me uni t for the
trace f ile. The value of the double argument shall be posi ti ve and shal l be a power of 10. In the
absence of any call f unction set_time_unit, the def aul t trace fi le ti me uni t shal l be 1 picosecond.
8.1.3 sc_create_vcd_trace_file
sc_trace_fi le* sc_create_vcd_tr ace_file( const char* name );
Function sc_create_vcd_tr ace_file shall create a new fi le handle obj ect of cl ass sc_trace_file, open
a new VCD f il e associ ated with the fi le handle, and return a pointer to the f il e handle. The fil e name
shal l be constructed by appending the character string .vcd to the character string passed as an
argument to the function.
8.1.4 sc_close_vcd_trace_file
void sc_close_vcd_tr ace_file( sc_trace_f il e* tf );
Function sc_close_vcd_tr ace_file shall cl ose the VCD f il e and delete the fi le handle poi nted to by
the argument.
8.1.5 sc_write_comment
void sc_wr ite_comment( sc_trace_f il e* tf , const std::string& comment );
Function sc_wr ite_comment shall wri te the stri ng given as the second argument to the trace fi le
given by the fi rst argument, as a comment, at the simul ati on time at which the f unction is call ed.
8.1.6 sc_trace
void sc_trace( sc_trace_f il e* , const bool& , const std::string& );
void sc_trace( sc_trace_f il e* , const bool* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const f loat& , const std::string& );
void sc_trace( sc_trace_f il e* , const f loat* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const double& , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const doubl e* , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_logi c& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_logic* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_int_base& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_int_base* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_ui nt_base& , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_ui nt_base* , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_signed& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_signed* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_unsigned& , const std::string& );
void sc_tr ace( sc_trace_f il e* , const sc_dt::sc_unsigned* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_bv_base& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_bv_base* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_l v_base& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_l v_base* , const std::stri ng& );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


387
Copyright 2012 IEEE. All rights reserved.
void sc_trace( sc_trace_f il e* , const sc_dt::sc_f xval& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_fxval * , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_fxval _fast& , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_fxval _f ast* , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_f xnum& , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_f xnum* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_fxnum_f ast& , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const sc_dt::sc_fxnum_f ast* , const std::stri ng& );
void sc_trace( sc_trace_f il e* , const unsi gned char& , const std::stri ng& ,
int width = 8 * si zeof( unsigned char ) );
void sc_trace( sc_trace_f il e* , const unsi gned char* , const std::string& ,
int width = 8 * si zeof( unsigned char ) );
void sc_trace( sc_trace_f il e* , const unsi gned short& , const std::string& ,
int width = 8 * si zeof( unsigned short ) );
void sc_trace( sc_trace_f il e* , const unsi gned short* , const std::stri ng& ,
int width = 8 * sizeof( unsigned short ) );
void sc_trace( sc_trace_f il e* , const unsi gned int& , const std::stri ng& ,
int width = 8 * si zeof( unsigned int ) );
void sc_trace( sc_trace_f il e* , const unsi gned int* , const std::string& ,
int width = 8 * si zeof( unsigned i nt ) );
void sc_trace( sc_trace_f il e* , const unsi gned long& , const std::stri ng& ,
int width = 8 * si zeof( unsigned l ong ) );
void sc_trace( sc_trace_f il e* , const unsi gned long* , const std::stri ng& ,
int width = 8 * si zeof( unsigned l ong ) );
void sc_trace( sc_trace_f il e* , const char& , const std::string& , int width = 8 * sizeof( char ) );
void sc_tr ace( sc_trace_f il e* , const char* , const std::string& , int width = 8 * sizeof( char ) );
void sc_trace( sc_trace_f il e* , const short& , const std::string& , int width = 8 * sizeof( short ) );
void sc_trace( sc_trace_f il e* , const short* , const std::string& , int wi dth = 8 * sizeof ( short ) );
void sc_trace( sc_trace_f il e* , const i nt& , const std::string& , int width = 8 * sizeof( int ) );
void sc_trace( sc_trace_f il e* , const i nt* , const std::string& , int width = 8 * si zeof( int ) );
void sc_trace( sc_trace_fi le* , const long& , const std::string& , int width = 8 * sizeof( l ong ) );
void sc_trace( sc_trace_f il e* , const l ong* , const std::string& , int width = 8 * sizeof ( l ong ) );
void sc_trace( sc_trace_f il e* , const sc_dt::i nt64& , const std::stri ng& ,
int width = 8 * si zeof( sc_dt::int64 ) );
void sc_trace( sc_trace_f il e* , const sc_dt::i nt64* , const std::string& ,
int width = 8 * si zeof( sc_dt::int64 ) );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


388
Copyright 2012 IEEE. All rights reserved.
void sc_trace( sc_trace_f il e* , const sc_dt::ui nt64& , const std::stri ng& ,
int width = 8 * sizeof( sc_dt::uint64 ) );
void sc_trace( sc_trace_f il e* , const sc_dt::uint64* , const std::stri ng& ,
int width = 8 * sizeof( sc_dt::uint64 ) );
templ ate <class T>
void sc_trace( sc_trace_f il e* , const sc_signal_in_i f<T>& , const std::string& );
void sc_trace( sc_trace_f il e* , const sc_signal_in_if <char>& , const std::string& , int width );
void sc_trace( sc_trace_f il e* , const sc_signal_in_if <short>& , const std::string& , int width );
void sc_trace( sc_trace_f il e* , const sc_signal_in_if <int>& , const std::stri ng& , i nt width );
void sc_trace( sc_trace_f il e* , const sc_signal_in_if <long>& , const std::string& , int width );
Function sc_trace shal l trace the val ue passed as the second argument to the trace f ile passed as the
f irst argument, usi ng the string passed as the thi rd argument to identif y the val ue in the trace fi le. All
changes to the value of the second argument that occur between the time the f unction i s cal led and
the ti me the trace f il e i s closed shall be recorded i n the trace f il e.
NOTEThe function sc_tr ace i s al so overl oaded el sewhere i n thi s standard to support addi ti onal data types
(see 6.8.4 and 6.10.5).
8.2 sc_report
8.2.1 Description
Cl ass sc_repor t represents an i nstance of a report as generated by functi on sc_repor t_handler ::repor t.
sc_repor t objects are accessi bl e to the appli cation i f the acti on SC_CACHE_REPORT is set for a given
severi ty l evel and message type. Also, sc_repor t objects may be caught by the appl ication when thrown by
the report handl er (see 8.3).
Type sc_sever ity represents the severity l evel of a report.
8.2.2 Class definition
namespace sc_core {
enum sc_severity {
SC_INFO = 0 ,
SC_WARNING ,
SC_ERROR ,
SC_FATAL ,
SC_MAX_SEVERI TY
} ;
enum sc_verbosity {
SC_NONE = 0,
SC_LOW = 100,
SC_MEDI UM = 200,
SC_HIGH = 300,
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


389
Copyright 2012 IEEE. All rights reserved.
SC_FULL = 400,
SC_DEBUG = 500
} ;
class sc_r epor t
: publi c std::excepti on
{
publ ic:
sc_repor t( const sc_report& );
sc_report& oper ator = ( const sc_report& );
virtual ~sc_r epor t() throw();
sc_severi ty get_severity() const;
const char* get_msg_type() const;
const char* get_msg() const;
int get_ver bosity() const;
const char* get_file_name() const;
int get_line_number() const;
const sc_time& get_time() const;
const char* get_process_name() const;
virtual const char* what() const throw();
} ;
} // namespace sc_core
8.2.3 Constraints on usage
Objects of cl ass sc_report are generated by cal li ng the f unction sc_repor t_handler ::repor t. An appl icati on
shal l not di rectly create a new obj ect of cl ass sc_repor t other than by call ing the copy constructor. The
indi vi dual attributes of an sc_repor t object may only be set by function sc_repor t_handler ::r epor t.
An implementati on shal l throw an object of class sc_repor t from f unction default_handler of cl ass
sc_r epor t_hander in response to the acti on SC_THROW. An appli cati on may throw an obj ect of class
sc_repor t f rom an appli cati on-specif ic report handl er f unction. An appl ication may catch an sc_repor t i n a
try-bl ock.
8.2.4 sc_verbosity
The enumerati on sc_ver bosity provides the values of i ndi cative verbosity level s that may be passed as
arguments to member f unction set_ver bosity_level of class sc_repor t_handler and to member f uncti on
report of class sc_report_handler.
8.2.5 sc_severity
There shal l be f our severity level s. SC_MAX_SEVERI TY shall not be a severi ty level . I t shall be an error to
pass the value SC_MAX_SEVERITY to a f uncti on requi ri ng an argument of type sc_sever ity.
Tabl e 50 describes the i ntended meanings of the four severity l evels. The precise meanings can be
overri dden by the class sc_report_handler .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


390
Copyright 2012 IEEE. All rights reserved.
8.2.6 Copy constructor and assignment
sc_repor t( const sc_report& );
sc_report& oper ator = ( const sc_report& );
The copy constructor and the assignment operator shall each create a deep copy of the sc_repor t
object passed as an argument.
8.2.7 Member functions
Several member functi ons specif ied i n thi s subclause return a pointer to a nul l-terminated character stri ng.
The impl ementation is only obl iged to keep the returned string vali d duri ng the li feti me of the sc_repor t
object.
sc_severi ty get_severity() const;
const char* get_msg_type() const;
const char* get_msg() const;
int get_ver bosity() const;
const char* get_file_name() const;
int get_line_number () const;
Each of these si x member functi ons shall return the corresponding property of the sc_repor t object.
The properti es themsel ves can only be set by passi ng thei r values as arguments to the f unction
sc_report_handler ::report. If the value of the severi ty l evel i s not SC_I NFO, the val ue returned
f rom get_ver bosity shall be i mplementati on-def ined.
const sc_time& get_time() const;
const char* get_process_name() const;
Each of these two member functi ons shall return the correspondi ng property of the sc_repor t object.
The properti es themselves shal l be set by f unction sc_r epor t_handler::r epor t accordi ng to the
simul ation time at whi ch the report was generated and the process i nstance wi thin which i t was
generated.
virtual const char* what() const;
Member functi on what shall return a text string composed f rom the severi ty level , message type,
message, f il e name, l ine number, process name, and ti me of the sc_repor t obj ect. An
impl ementation may vary the content of the text stri ng, depending on the severi ty l evel.
Table 50Levels for sc_severity
Sever ity levels Descr iption
SC_I NFO An inf ormati ve message
SC_WARNI NG A potenti al probl em
SC_ERROR An actual probl em f rom whi ch an
appl i cati on may be abl e to recover
SC_FATAL An actual probl em f rom whi ch an
appl i cati on cannot recover
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


391
Copyright 2012 IEEE. All rights reserved.
Exampl e:
try {
...
SC_REPORT_ERROR("msg_type", "msg");
...
} catch ( sc_report e) {
std::cout << "Caught " << e.what() << std::endl ;
}
8.3 sc_report_handler
8.3.1 Description
Cl asssc_report_handler provi des featuresfor wri ti ng out textual reportson the occurrenceof excepti onal
circumstances and for defini ng appli cation-specific behavior to be executed when those reports are
generated.
Member functi on report is thecentral feature of the reporti ng mechani sm, and by itsel f, it issufficient for
the generati on of reports usi ng the defaul t actions and defaul t handler. Other member functions of class
sc_report_handler provi de for appl icati on-speci fi c report handl ing. Member function report shal l be
cal led by an i mplementati on whenever it needs to report an excepti onal circumstance. Member function
report may al so be cal led from SystemC appli cati ons created by IP vendors, EDA tool vendors, or end
users. The intenti on i s that the behavi or of reports embedded i n an i mplementati on or in precompi led
SystemC codedistributed as obj ect code may bemodi fi ed by end usersto cal li ng the member functions of
class sc_report_handler.
Inorder to defi neappli cati on-specific actionstobetaken when areport isgenerated, reportsarecategori zed
accordi ng to their severity level and message type. Careshould betaken when choosing themessagetypes
passed to functi on report in order to gi vethe end user adequate control over thedefini ti on of actions. It is
recommended that each messagetypetakethefoll owi ng general form:
"/originati ng_company_or_insti tuti on/product_i dentifier/subcategory/subcategory..."
It istheresponsi bil ity of any party who di stri butesprecompil edSystemCcodeto ensurethat any reportsthat
theend user may need to disti ngui sh for thepurposeof setti ng acti onsareal located uniquemessagetypes.
8.3.2 Class definition
namespacesc_core{
typedef unsigned sc_actions;
enum {
SC_UNSPECIFIED = 0x0000,
SC_DO_NOTHING = 0x0001,
SC_THROW = 0x0002,
SC_LOG = 0x0004,
SC_DISPLAY = 0x0008,
SC_CACHE_REPORT = 0x0010,
SC_INTERRUPT = 0x0020,
SC_STOP = 0x0040,
SC_ABORT = 0x0080
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


392
Copyright 2012 IEEE. All rights reserved.
} ;
#def ine SC_DEFAULT_I NFO_ACTI ONS \
( SC_LOG | SC_DI SPLAY )
#def ine SC_DEFAULT_WARNI NG_ACTIONS \
( SC_LOG | SC_DI SPLAY )
#def ine SC_DEFAULT_ERROR_ACTIONS\
( SC_LOG | SC_CACHE_REPORT | SC_THROW )
#def ine SC_DEFAULT_FATAL_ACTI ONS \
( SC_LOG | SC_DISPLAY | SC_CACHE_REPORT | SC_ABORT )
typedef voi d ( * sc_report_handler _proc ) ( const sc_report& , const sc_actions& );
class sc_repor t_handler
{
publ ic:
stati c void report( sc_severity , const char* msg_type , const char* msg , const char* fi le , i nt li ne );
stati c void report( sc_severity , const char* msg_type , const char* msg , int verbosi ty,
const char* fi le , i nt li ne );
stati c sc_acti ons set_actions( sc_severity , sc_acti ons = SC_UNSPECI FIED );
stati c sc_acti ons set_actions( const char * msg_type , sc_actions = SC_UNSPECI FI ED );
stati c sc_acti ons set_actions( const char * msg_type , sc_severi ty , sc_acti ons = SC_UNSPECIFI ED );
stati c i nt stop_after ( sc_severity , int limit = 1 );
stati c i nt stop_after ( const char* msg_type , int limit = 1 );
stati c i nt stop_after ( const char* msg_type , sc_severity , int limit = 1 );
stati c i nt get_count( sc_severity );
stati c i nt get_count( const char* msg_type );
stati c i nt get_count( const char* msg_type , sc_severity );
int set_ver bosity_level( i nt );
int get_ver bosity_level();
stati c sc_acti ons suppr ess( sc_acti ons );
stati c sc_acti ons suppr ess();
stati c sc_acti ons for ce( sc_acti ons );
stati c sc_acti ons for ce();
stati c void set_handler ( sc_report_handl er_proc );
stati c void default_handler ( const sc_report& , const sc_actions& );
stati c sc_acti ons get_new_action_id();
stati c sc_report* get_cached_r epor t();
stati c void clear_cached_repor t();
stati c bool set_log_file_name( const char* );
stati c const char* get_log_file_name();
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


393
Copyright 2012 IEEE. All rights reserved.
#def ine SC_REPORT_I NFO_VERB( msg_type , msg, verbosity ) \
sc_report_handler::report( SC_I NFO , msg_type , msg , verbosi ty, __FI LE__ , __LI NE__ )
#def ine SC_REPORT_INFO( msg_type , msg ) \
sc_report_handler::report( SC_I NFO , msg_type , msg , __FILE__ , __LI NE__ )
#def ine SC_REPORT_WARNING( msg_type , msg ) \
sc_report_handler::report( SC_WARNI NG , msg_type , msg , __FILE__ , __LINE__ )
#def ine SC_REPORT_ERROR( msg_type , msg ) \
sc_report_handler::report( SC_ERROR , msg_type , msg , __FILE__ , __LINE__ )
#def ine SC_REPORT_FATAL( msg_type , msg ) \
sc_report_handler::report( SC_FATAL , msg_type , msg , __FILE__ , __LI NE__ )
#def ine sc_asser t( expr ) \
( ( voi d ) ( ( expr ) ? 0 : ( SC_REPORT_FATAL( i mpl ementati on-defi ned , #expr ) , 0 ) ) )
void sc_interr upt_here( const char* msg_type , sc_severi ty );
void sc_stop_her e( const char* msg_type , sc_severity );
} // namespace sc_core
8.3.3 Constraints on usage
The member f unctions of cl ass sc_report_handler can be cal led at any time duri ng elaborati on or
simul ation. Actions can be set f or a severi ty level or amessage type both bef ore and af ter the fi rst use of that
severi ty level or message type as an argument to member function report.
8.3.4 sc_actions
The typedef sc_actions represents a word where each bi t i n the word represents a di stinct acti on. More than
one bi t may be set, in whi ch case all of the corresponding actions shall be executed. The enumeration defi nes
the set of actions recognized and perf ormed by the def ault handler. An appl ication-speci fi c report handler
set by cal li ng f uncti on set_handler may modi fy or extend this set of acti ons.
The val ue SC_UNSPECIFI ED i s not an acti on as such but serves as the default value f or a variable or
argument of type sc_actions, meaning that no acti on has been set. I n contrast, the val ue SC_DO_NOTHING
is a specif ic acti on and shall inhi bit any acti ons set with a l ower precedence according to the rules given i n
8.3.6.
Each severi ty l evel i s associated with a set of defaul t acti ons chosen to be appropriate f or the given name,
but those def aul ts can be overri dden by cal li ng member functi on set_actions. The def aul t acti ons shal l be
def ined by the macros SC_DEFAULT_INFO_ACTIONS, SC_DEFAULT_WARNI NG_ACTI ONS,
SC_DEFAULT_ERROR_ACTI ONS, and SC_DEFAULT_FATAL_ACTIONS.
8.3.5 report
stati c void report( sc_severity , const char* msg_type , const char* msg , const char* fi le , i nt li ne );
stati c void report( sc_severity , const char* msg_type , const char* msg , i nt verbosi ty, const char* f il e ,
int line );
Member function report shal l generate a report and cause the appropriate acti ons to be taken as
def ined bel ow.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


394
Copyright 2012 IEEE. All rights reserved.
Member functi on report shall use the severi ty passed as the f irst argument and the message type
passed as the second argument to determine the set of acti ons to be executed as a resul t of previous
cal ls to f uncti ons set_actions, stop_after , suppr ess, and for ce. Member f unction report shal l
create an obj ect of class sc_repor t initiali zed usi ng all f ive argument values and shall pass this
object to the handler set by the member f unction set_handler . The obj ect of class sc_repor t shal l
not persist beyond the cal l to member f unction report unless the action SC_CACHE_REPORT i s
set, in which case the obj ect can be retri eved by call ing functi on get_cached_r epor ts. An
impl ementation shall maintain a separate cache of sc_repor t obj ects f or each process i nstance and a
single gl obal report cache f or cal ls to f uncti on report from outside any process. Each such cache
shal l store onl y the most recent report.
Member function report shall be responsi ble f or determini ng the set of acti ons to be executed. The
handl er function set by functi on set_handler shall be responsi bl e f or executing those actions.
Member function report shal l maintai n counts of the number of reports generated as descri bed i n
8.3.7. These counts shal l be i ncremented regardl ess of whether acti ons are executed or suppressed,
except where reports are i gnored due to thei r verbosi ty level , i n which case the counts shall not be
incremented.
I f the verbosi ty argument i s present, and the value of the severi ty argument is SC_I NFO, and the
val ue of the verbosi ty argument is greater than the maximum verbosity level , member functi on
report shall return wi thout executi ng any actions and without i ncrementi ng any counts. I f the
verbosi ty argument is absent and the val ue of the severity argument i s SC_I NFO, member functi on
report shall behave as if the verbosity argument were present and had a val ue of SC_MEDI UM. If
the severi ty argument has a val ue other than SC_I NFO, the impl ementation shal l i gnore the
verbosi ty argument.
The macros SC_REPORT_INFO_VERB, SC_REPORT_INFO, SC_REPORT_WARNI NG,
SC_REPORT_ERROR, SC_REPORT_FATAL, and sc_asser t are provided for conveni ence when
cal li ng member f unction report, but there is no obli gation on an appli cation to use these macros.
NOTEClass sc_repor t may provi de a constructor f or the excl usive use of class sc_r epor t_handler i n
i ni tial i zi ng these properti es.
8.3.6 set_actions
stati c sc_acti ons set_actions( sc_severity , sc_acti ons = SC_UNSPECI FIED );
stati c sc_acti ons set_actions( const char * msg_type , sc_actions = SC_UNSPECI FI ED );
stati c sc_acti ons set_actions( const char * msg_type , sc_severi ty , sc_acti ons = SC_UNSPECIFI ED );
Member function set_actions shal l set the actions to be taken by member f uncti on report when
report is call ed with the given severi ty level , message type, or both. In determini ng which set of
actions to take, the message type shall take precedence over the severity l evel, and the message type
and severity level combined shall take precedence over the message type and severi ty l evel
considered i ndi vidual ly. In other words, the three member functions set_actions just listed appear in
order of i ncreasing precedence. The actions of any lower precedence match shal l be inhibited.
Each call to set_actions shal l replace the actions set by the previous call f or the given severi ty,
message type, or severity-message type pai r. The value returned f rom the member f uncti on
set_actions shall be the actions set by the previous cal l to that very same overloadi ng of the f unction
set_actionsf or the given severi ty level , message type, or severity-message type pai r. The fi rst call to
f uncti on set_actions( sc_severity , sc_actions ) shall return the default actions associated wi th the
given severi ty level. The fi rst call to one of the remaini ng two f uncti ons f or a given message type
shal l return the value SC_UNSPECIFI ED. Each of the three overloaded f unctions operates
independently in thi s respect. Precedence is onl y relevant when report is cal led.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


395
Copyright 2012 IEEE. All rights reserved.
Exampl e:
sc_report_handler::set_actions(SC_WARNI NG, SC_DO_NOTHI NG);
sc_report_handler::set_actions("/Acme_IP", SC_DI SPLAY);
sc_report_handler::set_actions("/Acme_I P", SC_I NFO, SC_DI SPLAY | SC_CACHE_REPORT);
...
SC_REPORT_WARNING("", "1"); // Sil ence
SC_REPORT_WARNI NG("/Acme_IP", "2"); // Written to standard output
SC_REPORT_INFO("/Acme_IP", "3"); // Written to standard output and cached
8.3.7 stop_after
stati c i nt stop_after ( sc_severity , int limit = 1 );
stati c i nt stop_after ( const char* msg_type , int limit = 1 );
stati c i nt stop_after ( const char* msg_type , sc_severity , int limit = 1 );
Member f uncti on report shall maintai n i ndependent counts of the number of reports generated f or
each severity level, each message type, and each severi ty-message type pai r. Member function
stop_after shall set a l imit on the number of reports that wil l be generated i n each case. Member
f uncti on report shall cal l the function sc_stop when exactly the number of reports gi ven by
argument limit to function stop_after have been generated for the given severi ty level, message
type, or severi ty-message type pair.
I n determini ng when to call f uncti on sc_stop, the message type shall take precedence over the
severi ty level , and the message type and severi ty level combined shal l take precedence over the
message type and severity l evel consi dered indivi dual ly. In other words, the three member functions
stop_after j ust li sted appear i n order of i ncreasing precedence. I f functi on report i s cal led wi th a
combination of severity l evel and message type that matches more than one li mit set by cal li ng
stop_after , onl y the hi gher precedence l i mi t shal l have any eff ect.
The appropri ate counts shall be i ni ti alized to the value 1 the f irst ti me function report is called with
a parti cul ar severity level , message type, or severity-message type pai r and shal l not be modi fi ed or
reset when f unction stop_after is cal led. All three counts shall be i ncremented for each cal l to
f uncti on report whether or not any actions are executed. When a count for a particular severity-
message type pai r i s incremented, the counts f or the given severi ty level and the given message type
shal l be incremented also. I f the li mi t bei ng set has already been reached or exceeded by the count at
the time stop_after i s cal led, sc_stop shall not be cal led immediately but shal l be call ed the next
ti me the gi ven count is incremented.
The default limit is 1, which means that no stop limit is set. Calling function stop_after with a li mit
of 1 for a particular severity level, message type, or severi ty-message type pai r shall remove the
stop limit f or that parti cul ar case.
A limit of 0 shall mean that there i s no stop li mit f or the gi ven severity level , message type, or
severi ty-message type pai r, and, moreover an explici t l imi t of 0 shall overri de the behavior of any
lower precedence case. However, even with an expli cit li mi t of 0, the acti ons set f or the given case
(by cal ling function sc_action or the default acti ons) may nonethel ess result i n f uncti on sc_stop or
abor t bei ng called or an exception thrown.
I f f unction report i s call ed with a severity level of SC_FATAL, the default behavior in the absence
of any call s to either f unction set_actions or f uncti on stop_after is to execute a set of actions,
includi ng SC_ABORT.
The value returned from the member function stop_after shall be the l imit set by the previous cal l to
that very same overloading of the functi on stop_after f or the gi ven severity level , message type, or
severi ty-message type pair. Otherwi se, the value returned is the default limit of 1.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


396
Copyright 2012 IEEE. All rights reserved.
Exampl e 1:
sc_report_handler::stop_after(SC_WARNING, 1);
sc_report_handler::stop_after("/Acme_I P", 2);
sc_report_handler::stop_after("/Acme_I P", SC_WARNI NG, 3);
...
SC_REPORT_WARNING("/Acme_IP", "Overf low");
SC_REPORT_WARNI NG("/Acme_IP", "Confli ct");
SC_REPORT_WARNI NG("/Acme_IP", "Mi suse"); // sc_stop() call ed
Exampl e 2:
sc_report_handler::stop_after(SC_WARNING, 5);
sc_report_handler::stop_after("/Acme_I P", SC_WARNI NG, 1);
...
SC_REPORT_WARNI NG("/Star_IP", "Unexpected");
SC_REPORT_INFO("/Acme_IP", "I nvoked");
SC_REPORT_WARNI NG("/Acme_IP", "Mi stimed"); // sc_stop() call ed
8.3.8 get_count
stati c i nt get_count( sc_severity );
stati c i nt get_count( const char* msg_type );
stati c i nt get_count( const char* msg_type , sc_severity );
Member f unction get_count shal l return the count of the number of reports generated for each
severi ty level , each message type, and each severity-message type pair mai ntained by member
f uncti on report. I f member functi on report has not been call ed for the given severi ty l evel , message
type, or severi ty-message type pair, member function get_count shall return the value zero.
8.3.9 Verbosity level
The maximum verbosity level is a single gl obal quantity that shal l only apply to reports wi th a severi ty level
of SC_I NFO. Any i ndi vidual reports having a severity l evel of SC_I NFO and a verbosity level greater than
the maxi mum verbosi ty level shall be i gnored; that is, the i mplementati on shall in eff ect suppress al l the
actions associated with that report.
int set_ver bosity_level( i nt );
Member functi on set_ver bosity_level shal l set the maxi mum verbosity l evel to the val ue passed as
an argument and shal l return the previ ous value of the maxi mum verbosity level as the value of the
f uncti on.
int get_ver bosity_level();
Member f uncti on get_ver bosity_level shall return the value of the maximum verbosi ty level.
8.3.10 suppress and force
stati c sc_acti ons suppr ess( sc_acti ons );
stati c sc_acti ons suppr ess();
Member function suppr essshall suppress the executi on of a given set of actions for subsequent cal ls
to function report. The acti ons to be suppressed are passed as an argument to f unction suppr ess.
The return value f rom f uncti on suppr ess shall be the set of actions that were suppressed
immedi ately prior to the call to function suppr ess. The acti ons passed as an argument shal l replace
entirely the previ ously suppressed acti ons, there bei ng onl y a si ngl e, global set of suppressed
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


397
Copyright 2012 IEEE. All rights reserved.
actions. By def aul t, there are no suppressed acti ons. I f the argument l ist i s empty, the set of
suppressed actions shal l be cl eared, restori ng the default behavi or.
The suppressi on of certai n actions shall not hinder the execution of any other actions that are not
suppressed.
stati c sc_acti ons for ce( sc_acti ons );
stati c sc_acti ons for ce();
Member f uncti on for ce shall force the execution of a gi ven set of actions f or subsequent cal ls to
f uncti on report. The actions to be f orced are passed as an argument to function for ce. The return
val ue f rom f uncti on for ce shall be the set of acti ons that were forced immedi atel y prior to the call to
f uncti on for ce. The actions passed as an argument shal l repl ace entirel y the previ ously f orced
actions, there being only a single, gl obal set of f orced actions. By def aul t, there are no f orced
actions. If the argument l ist i s empty, the set of forced actions shal l be cleared, restori ng the def aul t
behavior.
Forced acti ons shal l be executed i n addi ti on to the def aul t actions for the gi ven severity l evel and in
addi ti on to any acti ons set by cal li ng f unction set_actions.
I f the same action is both suppressed and forced, the f orce shal l take precedence.
8.3.11 set_handler
typedef voi d ( * sc_report_handler _proc ) ( const sc_report& , const sc_actions& );
stati c void set_handler ( sc_report_handl er_proc );
Member f unction set_handler shal l set the handler function to be cal led from f uncti on report. This
all ows an appli cati on-specif ic report handler to be provided.
stati c void default_handler( const sc_report& , const sc_actions& );
Member function default_handler shal l be the def aul t handl er; that is, member f uncti on
default_handler shall be cal led f rom f uncti on report in the absence of any cal l to f uncti on
set_handler . Member f uncti on default_handler shall perf orm zero, one, or more than one of the
actions set out in Table 51, as determi ned by the value of i ts second argument. In thi s table, the
composi te message shall be a text string composed f rom the severity l evel, message type, message,
f ile name, li ne number, process name, and time of the sc_repor t obj ect. An impl ementation may
vary the content of the composi te message, dependi ng on the severi ty level .
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


398
Copyright 2012 IEEE. All rights reserved.
NOTETo restore the default handl er, cal l set_handler( &sc_report_handl er::def aul t_handl er ).
8.3.12 get_new_action_id
stati c sc_acti ons get_new_action_id();
Member function get_new_action_id shal l return a val ue of type sc_actions that represents an
unused acti on. The returned value shall be a word with exactly one bit set. The intenti on i s that such
a val ue can be used to extend the set of actions when wri ti ng an application-specif ic report handl er.
I f there are no more uni que val ues available, the f unction shal l return the value SC_UNSPECI FIED.
An appl ication shall not call function get_new_action_id bef ore the start of elaborati on.
8.3.13 sc_interrupt_here and sc_stop_here
void sc_interr upt_here( const char* msg_type , sc_severi ty );
void sc_stop_her e( const char* msg_type , sc_severity );
Functions sc_interr upt_here and sc_stop_her e shall be cal led from member f unction
default_handler in response to acti on types SC_INTERRUPT and SC_STOP, respecti vel y. These
two functi ons may al so be cal led f rom appli cation-specif ic report handl ers. The intenti on is that
these two f unctions serve as a debugging ai d by al lowi ng a user to set a breakpoint on or within
either f uncti on. To this end, an impl ementation may choose to impl ement each of these f unctions
wi th a swi tch statement dependent on the severity parameter such that a user can set a breakpoi nt
dependent on the severi ty level of the report.
8.3.14 get_cached_report and clear_cached_report
stati c sc_report* get_cached_r epor t();
Member functi on get_cached_r epor t shall return a poi nter to the most recentl y cached report for
the current process i nstance if cal led f rom a process or the gl obal cache otherwi se. Previ ous reports
shal l not be accessi bl e.
Table 51Actions by default_handler
Sever ity levels Descr iption
SC_UNSPECI FIED No acti on (but f uncti on r epor t wi l l execute any l ower precedence acti ons).
SC_DO_NOTHI NG No acti on (but causes f uncti on repor t to i nhi bi t l ower precedence acti ons).
SC_THROW Throw the sc_repor t obj ect.
SC_LOG Wri te the composite message to the l og fi l e as set by f uncti on
set_log_file_name.
SC_DI SPLAY Wri te the composi te message to standard output.
SC_CACHE_REPORT No acti on (but causes f uncti on repor t to cache the report).
SC_I NTERRUPT Call f uncti on sc_inter r upt_her e, passi ng the message typeand severi ty l evel of
thesc_r epor t obj ect as arguments.
SC_STOP Call f uncti on sc_stop_her e, passi ng the message type and severi ty l evel of the
sc_r epor t obj ect as arguments, then cal l f uncti on sc_stop.
SC_ABORT Call abor t().
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


399
Copyright 2012 IEEE. All rights reserved.
stati c void clear_cached_repor t();
Member functi on clear_cached_repor t shall empty the report cache for the current process instance
if call ed from a process or the global cache otherwi se. A subsequent cal l to get_cached_r epor t
would return a null pointer until such a time as a further report was cached i n the gi ven cache.
8.3.15 set_log_file_name and get_log_file_name
stati c bool set_log_file_name( const char* );
stati c const char* get_log_file_name();
Member f unction set_log_file_name shal l set the log fi le name. Member functi on
get_log_file_name shal l return the log fi le name as set by set_log_file_name. The default val ue f or
the l og fi le name is a null pointer. If f uncti on set_log_file_name i s cal led with a non-nul l poi nter
and there is no existi ng log fi le name, the log f il e name shall be set by dupli cating the string passed
as an argument and the functi on shall return true. I f cal led with a non-null pointer and there is
already a l og f il e name, functi on set_log_file_name shall not modif y the exi sting name and shal l
return false. If call ed wi th a null poi nter, any exi sting log f il e name shall be del eted and the functi on
shal l return false.
Openi ng, writing, and cl osing the log fi le shal l be the responsi bi li ty of the report handl er. Member
f uncti on default_handler shall cal l function get_log_file_name in response to the action SC_LOG.
Function get_log_file_name may al so be call ed f rom an appli cation-specif ic report handler.
Exampl e:
sc_report_handler::set_log_fi le_name("foo"); // Returns true
sc_report_handler::get_log_fil e_name(); // Returns "foo"
sc_report_handler::set_log_fi le_name("bar"); // Returns f alse
sc_report_handler::get_log_fil e_name(); // Returns "foo"
sc_report_handler::set_log_fil e_name(0); // Returns f al se
sc_report_handler::get_log_fi le_name(); // Returns 0
8.4 sc_exception
8.4.1 Description
Cl ass sc_repor t, which represents a report generated by the SystemC report handl er, is derived from cl ass
std::exception. The typedef sc_exception exists to provi de a degree of backward compati bi li ty wi th earli er
versions of the SystemC class li brary (see 8.2).
8.4.2 Class definition
namespace sc_core {
typedef std::exception sc_exception;
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


400
Copyright 2012 IEEE. All rights reserved.
8.5 sc_vector
8.5.1 Description
Cl asssc_vector i s used to construct vectors of modules, channel s, ports, exports, or objects of any other type
that is derived from sc_object. As such i t provides a convenient way of describi ng repeti ti ve or
parameteri zed structures. Classsc_vector provi des member functi ons f or pi cki ng out elements f rom a vector
and f or port bi ndi ng, i ncluding member f uncti ons to bind a vector-of-ports to a vector-of-obj ects.
Function sc_assemble_vector (together with i ts associated proxy cl ass sc_vector_assembly) provi des a
mechanism f or assembl ing a vector of objects from a set of indivi dual obj ects di stributed across a vector of
modules. Such a vector assembly can be used in place of a vector i n many contexts, such as when bi ndi ng
ports.
Cl ass sc_vector provi des a mechanism for passi ng through user-defi ned module constructor arguments
when creati ng a vector of modul es.
Throughout the current clause onl y, the term vector refers to an object of type sc_vector<T > for some
appropriate choice of T.
8.5.2 Class definition
namespace sc_core {
class sc_vector_base : publ ic sc_obj ect
{
publ ic:
typedef i mpl ementati on-defi ned size_type;
virtual const char* kind() const;
size_type size() const;
const std::vector<sc_object* >& get_elements() const;
} ;
templ ate< typename T >
class sc_vector_i ter

: publi c std::i terator< std::random_access_iterator_tag, T >


{
// Conforms to Random Access I terator category.
// See ISO/IEC 14882:2003(E), 24.1 [ lib.iterator.requi rements]
i mpl ementati on-defi ned
} ;
templ ate< typename T >
class sc_vector : publi c sc_vector_base
{
publ ic:
usi ng sc_vector_base::size_type;
typedef sc_vector_i ter

<T> iterator;
typedef sc_vector_i ter

<const T> const_iter ator ;



sc_vector ();
expl icit sc_vector( const char* );
sc_vector ( const char* , si ze_type );
templ ate< typename Creator >
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


401
Copyright 2012 IEEE. All rights reserved.
sc_vector ( const char* , si ze_type , Creator );
virtual ~sc_vector();
void init( size_type );
stati c T* create_el ement( const char* , size_type );
templ ate< typename Creator >
void init( size_type , Creator );
T& oper ator [] ( size_type );
const T& oper ator [] ( size_type ) const;
T& at( size_type );
const T& at( si ze_type ) const;
iterator begin();
iterator end();
const_i terator begin() const;
const_i terator end() const;
const_i terator cbegin() const;
const_i terator cend() const;
templ ate< typename Contai nerType, typename ArgumentType >
iterator bind( sc_vector_assembly<ContainerType,ArgumentType> );
templ ate< typename Bindabl eContai ner >
iterator bind( Bi ndableContainer& );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator , iterator );
templ ate< typename Contai nerType, typename ArgumentType >
iterator oper ator () ( sc_vector_assembly<Contai nerType,ArgumentType> c );
templ ate< typename ArgumentContainer >
iterator oper ator () ( ArgumentContainer& );
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator );
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator , i terator );
pri vate:
// Di sabl ed
sc_vector( const sc_vector& );
sc_vector& oper ator = ( const sc_vector& );
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


402
Copyright 2012 IEEE. All rights reserved.
templ ate< typename T, typename MT >
class sc_vector_assembly
{
publ ic:
typedef i mpl ementati on-defi ned size_type;
typedef i mpl ementati on-defi ned iterator;
typedef i mpl ementati on-defi ned const_iter ator ;
typedef MT (T::* member _type);
sc_vector_assembly( const sc_vector_assembl y& );
iterator begin();
iterator end();
const_i terator begin() const;
const_i terator end() const;
const_i terator cbegin() const;
const_i terator cend() const;
size_type size() const;
std::vector< sc_obj ect* > get_elements() const;
iterator::reference oper ator [] ( size_type );
const_i terator::reference oper ator [] ( size_type ) const;
iterator::reference at( si ze_type );
const_i terator::reference at( si ze_type ) const;
templ ate< typename Contai nerType, typename ArgumentType >
iterator bind( sc_vector_assembly<Contai nerType, ArgumentType> );
templ ate< typename Bindabl eContainer >
iterator bind( Bi ndableContainer& );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator , iterator );
templ ate< typename BindableI terator >
iterator bind( BindableI terator , BindableI terator , sc_vector<T>::i terator );
templ ate< typename Contai nerType, typename ArgumentType >
iterator oper ator () ( sc_vector_assembly<Contai nerType, ArgumentType> );
templ ate< typename ArgumentContainer >
iterator oper ator () ( ArgumentContainer& );
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


403
Copyright 2012 IEEE. All rights reserved.
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator , i terator );
templ ate< typename ArgumentIterator >
iterator oper ator ()( ArgumentIterator , ArgumentIterator , sc_vector<T>::iterator );
pri vate:
// Di sabl ed
sc_vector_assembly& oper ator =( const sc_vector_assembl y& );
} ;
templ ate< typename T, typename MT >
sc_vector_assembly<T,MT> sc_assemble_vector ( sc_vector<T> & , MT (T::* member_ptr ) );
} // namespace sc_core
8.5.3 Constraints on usage
An appl ication shal l only instanti ate the template sc_vector<T > wi th a template argument T that is a type
derived from sc_object. Except where used wi th a custom creator , type T shal l provi de a constructor wi th a
single argument of a type that is convertibl e from const char* . I f an applicati on needs to pass additional
arguments to the el ement constructor, i t can use a creator functi on or f uncti on obj ect (see 8.5.5).
The constraints on when an obj ect of type sc_vector<T > may be constructed are dependent on the choi ce of
the template argument T. Subj ect only to any such constraints that apply to type T itself , vectors may be
constructed dynami cal ly during simul ation. For example, a vector-of -modul es can onl y be constructed
during elaboration.
The si ze of a vector can only be set once, ei ther when the vector i s constructed or usi ng a call to member
functi on init. Vectors cannot be resi zed dynamicall y.
8.5.4 Constructors and destructors
sc_vector();
expl icit sc_vector ( const char* );
sc_vector( const char* , si ze_type );
templ ate< typename Creator >
sc_vector( const char* , size_type , Creator );
The above constructors shal l pass the character stri ng argument (i f there i s one) through to the
constructor bel onging to the base cl ass sc_object i n order to set the string name of the vector
instance i n the module hierarchy.
The def aul t constructor shall cal l f unction sc_gen_unique_name(" vector" ) i n order to generate a
unique string name that i t shal l then pass through to the constructor for the base cl ass sc_object.
I f the second argument i s present, the constructor shal l cal l the member f uncti on init, passi ng
through the val ue of this second argument as the fi rst argument to init. Otherwi se the constructor
shal l construct an empty vector that may subsequently be ini ti al ized by call ing member f unction init
expl icitly.
I f the second and third arguments are present, the constructor shal l call the member f uncti on init,
passing through the val ues of the second and third arguments as the f irst and second arguments to
init.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


404
Copyright 2012 IEEE. All rights reserved.
Exampl e:
sc_vector< sc_port<i_f> > ports;
sc_vector< sc_signal<bool > > si gnal s;
...
SC_CTOR(my_module)
: ports ("ports", 4) // Vector-of -ports with 4 elements
, si gnal s("si gnals") // Uninitial ized vector-of -signals
{
signal s.i nit(8); // I nitiali ze the vector with 8 elements, each one a signal
}
virtual ~sc_vector ();
The destructor shall del ete every el ement of the vector.
8.5.5 init and create_element
void init( size_type );
stati c T* create_element( const char* , si ze_type );
Stati c member functi on create_element shal l all ocate and return a poi nter to a new object of type T
wi th the stri ng name given by its fi rst argument. The newly created obj ect shal l have the same parent
as the vector; that i s, the elements of a vector shall be sibl ings of the vector obj ect itsel f in the
SystemC object hierarchy. The reason for the existence of thi s f unction is that an appli cation may
provide an al ternati ve function i n order to pass user-defi ned constructor arguments to each element
of the vector(see below).
Member function init shall all ocate the number of objects of type T given by the value of its
argument and shal l populate the vector wi th those objects. Each object shall be all ocated by call ing
the f uncti on create_element, where the fi rst argument shall be set to the string name of the element
and the second argument shall be set to the number of the el ement i n the vector, counti ng up from 0.
The string name of each el ement shal l be determi ned by call ing the f uncti on
sc_gen_unique_name(this->basename()).
Call ing member functi on init with an argument value of 0 shal l be permi tted and shal l have no
eff ect.
I t shall be an error to cal l member f unction init more than once with an argument value greater than
0 for any given vector. Note that since a constructor wi th a second argument cal ls init, it shall be an
error to both construct a vector wi th a si ze and to call init, assuming the si ze i s nonzero i n both
cases.
templ ate< typename Creator >
void init( size_type , Creator c );
I nstead of cal li ng create_element, member f unction templ ate init shall use the value of the second
argument, whi ch may be a f uncti on or a f unction object, to all ocate each element of the vector. The
val ue passed as the second argument c must be such that
T* pl acehol der1 = c( (const char* )placeholder2, (size_type)placeholder3 );
is a wel l-formed statement. I n other words, the actual argument must be callable i n place of
create_element. This all ows the creator to be used to pass addi ti onal constructor arguments to each
element of the vector, rather than passing the stri ng name onl y.
The expressions V.init(N, sc_vector <T>::create_element) and V.init(N) shal l be equivalent f or all
vectors V.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


405
Copyright 2012 IEEE. All rights reserved.
Exampl e:
struct my_module: sc_modul e
{
my_modul e(sc_module_name n, stri ng extra_arg );
...
} ;

struct Top: sc_modul e
{
sc_vector<my_module> vector1; // Vector-of-modul es
sc_vector<my_module> vector2;

// Case 1: creator i s a function object
struct my_module_creator
{
my_modul e_creator( string arg ) : extra_arg(arg) { }

my_modul e* operator() (const char* name, si ze_t)
{
return new my_module(name, extra_arg );
}
string extra_arg;
} ;

// Case 2: creator i s a member functi on
my_modul e* my_module_creator_func( const char* name, size_t i )
{
return new my_modul e( name, "value_of _extra_arg" );
}

Top(sc_module_name _name, i nt N)
{
// Ini ti al ize vector passing through constructor arguments to my_module
// Case 1: construct and pass i n a f unction obj ect
vector1.init(N, my_module_creator("val ue_of_extra_arg"));

// Case 2: pass i n a member f unction usi ng Boost bi nd
vector2.init(N,
sc_bind( & M::my_modul e_creator_f unc, thi s, sc_unnamed::_1, sc_unnamed::_2 ) );
}
} ;
8.5.6 kind, size, get_elements
virtual const char* kind() const;
Member f uncti on kind shal l return the string "sc_vector".
size_type size() const;
Member function size shal l return the number of elements i n the vector. In the case of an
uninitiali zed vector, the si ze shall be 0. Once set to a nonzero value, the si ze cannot be modi fi ed.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


406
Copyright 2012 IEEE. All rights reserved.
const std::vector <sc_object* >& get_elements() const;
Member f unction get_elements of class sc_vector shall return a const ref erence to a std::vector
that contains pointers to the el ements of the sc_vector , one poi nter per element, in the same order.
The std::vector shall have the same si ze as the sc_vector. The ref erence shall be vali d f or the
li fetime of the sc_vector obj ect.
8.5.7 operator[] and at
T& oper ator [] ( size_type );
const T& oper ator [] ( size_type ) const;
T& at( size_type );
const T& at( si ze_type ) const;
oper ator [] and member f unctions at shal l each return a reference or const-qual if ied reference to the
object stored at the index posi ti on withi n the vector gi ven by the value of their one-and-only
argument. The reference shall be vali d f or the li feti me of the vector. I f the value of the argument is
greater than the si ze of the vector, the behavior of oper ator [] i s undef ined, whereas member
f uncti on at shall detect and report the error.
The value of the relati on & V[i] + j == & V[i + j ] is undef ined f or al l vectors v and f or al l indices i
and j .
8.5.8 Iterators
iterator begin();
iterator end();
const_i terator begin() const;
const_i terator end() const;
const_i terator cbegin() const;
const_i terator cend() const;
Cl ass sc_vector shall provide an iterator interface that f ulf ils the Random Access Iterator
requirements as defi ned in I SO/I EC 14882:2003(E), Clause 24.1 [ lib.i terator.requirements] .
begin shall return an iterator that ref ers to the f irst el ement of the vector. end shall return an i terator
that ref ers to an i magi nary element f oll owing the l ast element of the vector. I f the vector i s empty,
then begin() == end().
Type iterator shall be impl icitly convertible to type const_iter ator , where the conversi on shall
preserve the i denti ty of the element being referred to by the i terator.
Type sc_vector_assembly<T,M T>::iter ator shal l be impl icitly convertible both to type
sc_vector<T>::iter ator and to type sc_vector<T >::const_iterator, where the conversion shall
preserve the i denti ty of the element being referred to by the i terator.
Type sc_vector_assembly<T,M T>::const_iterator shall be i mpli ci tl y converti bl e to type
sc_vector<T>::const_iterator , where the conversion shall preserve the i dentity of the element
bei ng referred to by the iterator.
8.5.9 bind
templ ate< typename Contai nerType, typename ArgumentType >
iterator bind( sc_vector_assembly<ContainerType,ArgumentType> );
templ ate< typename Bindabl eContainer >
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


407
Copyright 2012 IEEE. All rights reserved.
iterator bind( Bi ndableContainer& );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator );
templ ate< typename Bindabl eI terator >
iterator bind( BindableI terator , BindableI terator , iterator );
templ ate< typename Contai nerType, typename ArgumentType >
iterator oper ator () ( sc_vector_assembly<Contai nerType,ArgumentType> c );
templ ate< typename ArgumentContainer >
iterator oper ator () ( ArgumentContainer& );
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator );
templ ate< typename ArgumentIterator >
iterator oper ator () ( ArgumentIterator , ArgumentIterator , iterator );
Each member f uncti on bind and oper ator () shall perform element-by-element bi ndi ng of the elements of
the current vector * this to the elements of the vector determi ned by the arguments to the f uncti on call . I n
each case, the impl ementation shal l bi nd the el ements by cal li ng function bind or oper ator (), respectively,
of each indi vi dual el ement of the current vector.
These functions exist i n mul ti ple forms that support partial bi ndi ng of either vector as fol lows:
The one- and two-argument forms shall start bi ndi ng from the f irst el ement of the current object. The three-
argument f orms shall start binding from the element referred to by the iterator passed as the third argument.
I f the thi rd argument does not refer to an el ement of the current object, the behavi or shal l be undefined.
The one-argument f orms shall start binding to the f irst element of the container passed as an argument,
which may be a vector or a vector assembly, and may bind to every el ement of that contai ner. The two- and
three-argument forms shall start binding to the element ref erred to by the i terator passed as the f irst
argument and shal l not bi nd any element i ncl udi ng or fol lowing that referred to by the iterator passed as the
second argument.
I n each case, member f uncti on bind and oper ator () shal l return an i terator that ref ers to the fi rst unbound
element within the current vector * thisafter the bi nding has been perf ormed.
A gi ven vector may be bound mul ti pl e times subj ect only to the binding pol icy of the i ndi vidual el ements. In
other words, it i s possi ble to make mul tipl e call s to bind, each call bi ndi ng di ff erent elements of a vector.
Exampl e:
typedef sc_vector<sc_inout<i nt> > port_type;
typedef sc_vector<sc_si gnal <int> > signal_type;

struct M: sc_module
{
port_type ports; // Vector-of -ports
M(sc_module_name _name, int N)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


408
Copyright 2012 IEEE. All rights reserved.
: ports("ports", N)
...
} ;

struct Top: sc_modul e
{
signal _type si gs; // Vector-of -signals

M * m1, * m2;

Top(sc_module_name _name)
: sigs ("si gs" , 4)
, hi_si gs ("hi_si gs" , 2)
, lo_si gs ("lo_si gs" , 2)
{
m1 = new M("m1", 4);
m2 = new M("m2", 4);

port_type::iterator i t;

// Bind all 4 elements of ports vector to all 4 elements of si gs vector
it = m1->ports.bi nd( si gs );
sc_assert( (i t - m1->ports.begin()) == 4 );

// Bind fi rst 2 elements of ports vector to 2 el ements of hi _si gs vector
it = m2->ports.bi nd( hi _si gs.begi n(), hi _sigs.end() );
sc_assert( (i t - m2->ports.begin()) == 2 );

// Expl icit loop equivalent to the above vector bi nd
// port_type::iterator from;
// si gnal _type::i terator to;
//
// for ( from = m2->ports.begi n(), to = hi _si gs.begi n();
// (f rom ! = m2->ports.end()) & & (to != hi_sigs.end());
// from++, to++ )
// (* f rom).bi nd( * to );

// Bind last 2 el ements of ports vector to 2 elements of lo_si gs vector
it = m2->ports.bi nd( lo_si gs.begin(), lo_si gs.end(), i t);
sc_assert( (i t - m2->ports.begin()) == 4 );
}
...
} ;
8.5.10 sc_assemble_vector
templ ate< typename T, typename MT >
sc_vector_assembly<T,MT> sc_assemble_vector ( sc_vector<T> & , MT (T::* member_ptr ) );
Function sc_assemble_vector shall return an obj ect of cl ass sc_vector_assembly, whi ch shal l serve
as a proxy for sc_vector by provi di ng the member functions begin, end, cbegin, cend, size,
get_elements, oper ator [], at, bind, and oper ator (). Each of these member f unctions shal l have the
same behavi or as the corresponding member f unctions of class sc_vector f or the vector represented
by this proxy.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


409
Copyright 2012 IEEE. All rights reserved.
The f irst argument passed to f unction sc_assemble_vector by the appli cati on shal l be an object of
type sc_vector<T>, where type T is a type deri ved from class sc_module. I n other words, the f irst
argument shal l be a vector-of -modules.
The second argument passed to function sc_assemble_vector by the appli cati on shal l be the address
of a member sub-obj ect of the user-def ined modul e class that f orms the type of the elements of the
vector passed as the f irst argument. In other words, the second argument shal l be a member of the
module from the fi rst argument.
The vector represented by the object of the proxy cl ass sc_vector_assembly shall contai n elements
consisti ng of references to the member sub-obj ects (as specif ied by the second argument) of every
element of the vector-of -modules (as speci fi ed by the fi rst argument).
sc_assemble_vector may be used to create a proxy f or a vector of any object type derived f rom the
class sc_object.
A cal l to any member functi on of the obj ect of class sc_vector_assembly shall act on the elements
of the vector represented by the proxy; that i s, the member sub-obj ects identif ied by the second
argument that are actuall y di stri buted across the members of the vector identi fi ed by the fi rst
argument. These sub-obj ects shall appear to be members of a single vector with respect to the
behavior of each of these member functi ons. As a consequence, the f ollowi ng relati ons shall hol d:
sc_vector_assembl y<T, MT> assembl y = sc_assemble_vector(vector, & modul e_type::member);

sc_assert( &* (assembl y.begin()) == &(* vector.begin()).member );
sc_assert( &* (assembl y.end()) == &(* vector.end()).member );
sc_assert( assembly.size() == vector.size() );

f or (unsigned i nt i = 0; i < assembly.size(); i++)
{
sc_assert( &assembly[ i] == &vector[i ].member );
sc_assert( &assembly.at(i) == &vector[ i] .member );
}
Member function get_elements of class sc_vector_assembly shall return an object of type
std::vector<sc_obj ect* > by val ue. Each el ement of thi s std::vector shal l be set by stati cal ly casti ng
the member pointers in the vector assembl y to type sc_object* .
An appl ication shall not construct an object of class sc_vector_assembly except by call ing
sc_assemble_vector .
Cl ass sc_vector_assembly shal l be copyable.
Exampl e:
struct I nit: sc_module
{
sc_port<i_f> port;
...
struct Targ: publ ic sc_modul e, private i_f
{
sc_export<i _f > xp;
...
struct Top: sc_modul e
{
sc_vector<I ni t> i ni t_vec;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


410
Copyright 2012 IEEE. All rights reserved.
sc_vector<Targ> targ_vec;
...
Top(sc_module_name _name, i nt N)
: i nit_vec("ini t_vec", N)
, targ_vec("targ_vec", N)
{
// Vector-to-vector bind f rom vector-of-ports to vector-of -exports
sc_assemble_vector(i ni t_vec, &I nit::port).bi nd( sc_assemble_vector(targ_vec, &Targ::xp) );
...
8.6 Utility functions
8.6.1 Function declarations
namespace sc_dt {
templ ate <class T>
const T sc_abs( const T& );
templ ate <class T>
const T sc_max( const T& a , const T& b ) { return (( a >= b ) ? a : b ); }
templ ate <class T>
const T sc_min( const T& a , const T& b ) { return (( a <= b ) ? a : b ); }
}
namespace sc_core {
#def ine IEEE_1666_SYSTEMC 201101L

#def ine SC_VERSI ON_MAJOR i mpl ementati on-defi ned_number
#def ine SC_VERSI ON_MI NOR i mpl ementati on-defi ned_number
#def ine SC_VERSI ON_PATCH i mpl ementati on-defi ned_number
#def ine SC_VERSI ON_ORI GINATOR i mpl ementati on-defi ned_str i ng
#def ine SC_VERSION_RELEASE_DATE i mpl ementati on-defi ned_date
#def ine SC_VERSI ON_PRERELEASE i mpl ementati on-defi ned_str i ng
#def ine SC_I S_PRERELEASE i mpl ementati on-defi ned_bool
#def ine SC_VERSI ON i mpl ementati on-defi ned_str i ng
#def ine SC_COPYRIGHT i mpl ementati on-defi ned_str i ng
extern const unsi gned int sc_version_major;
extern const unsi gned int sc_ver sion_minor;
extern const unsi gned int sc_version_patch;
extern const std::stri ng sc_ver sion_originator;
extern const std::stri ng sc_version_r elease_date;
extern const std::stri ng sc_version_prer elease;
extern const bool sc_is_pr er elease;
extern const std::stri ng sc_version_str ing;
extern const std::stri ng sc_copyr ight_string;
const char* sc_copyr ight();
const char* sc_version();
const char* sc_release();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


411
Copyright 2012 IEEE. All rights reserved.
}
8.6.2 sc_abs
templ ate <class T>
const T sc_abs( const T& );
Function sc_absshall return the absolute val ue of the argument. Thi s f uncti on shal l be i mplemented
by call ing the operators bool T::operator >=( const T& ) and T T::oper ator-(), and hence, the
templ ate argument can be any SystemC numeric type or any fundamental C++ type.
8.6.3 sc_max
templ ate <class T>
const T sc_max( const T& a , const T& b ) { return (( a >= b ) ? a : b ); }
Function sc_max shall return the greater of the two val ues passed as arguments as defi ned above.
NOTEThe template argument should be a type for which oper ator >= i s def ined or f or whi ch a user-def i ned
conversi on to such a type i s def i ned, such as any SystemC numeri c type or any f undamental C++ type.
8.6.4 sc_min
templ ate <class T>
const T sc_min( const T& a , const T& b ) { return (( a <= b ) ? a : b ); }
Function sc_min shal l return the lesser of the two values passed as arguments as defi ned above.
NOTEThe template argument should be a type for which oper ator <= i s def ined or f or whi ch a user-def i ned
conversi on to such a type i s def i ned, such as any SystemC numeri c type or any f undamental C++ type.
8.6.5 Version and copyright
#def ine IEEE_1666_SYSTEMC 201101L
The i mplementati on shal l defi ne the macro IEEE_1666_SYSTEMC wi th preci sel y the value gi ven
above. It is the intent that future versions of this standard wil l replace the value of this macro with a
numeri call y greater val ue.
#def ine SC_VERSI ON_MAJOR i mpl ementati on-defi ned_number // For exampl e, 2
#def ine SC_VERSI ON_MI NOR i mpl ementati on-defi ned_number // 3
#def ine SC_VERSI ON_PATCH i mpl ementati on-defi ned_number // 4
#def ine SC_VERSI ON_ORI GINATOR i mpl ementati on-defi ned_stri ng // "OSCI"
#def ine SC_VERSION_RELEASE_DATE i mpl ementati on-defi ned_date // "20110411"
#def ine SC_VERSI ON_PRERELEASE i mpl ementati on-defi ned_stri ng // "beta"
#def ine SC_I S_PRERELEASE i mpl ementati on-defi ned_bool // 1
#def ine SC_VERSI ON i mpl ementati on-defi ned_stri ng // "2.3.4_beta-OSCI"
#def ine SC_COPYRIGHT i mpl ementati on-defi ned_stri ng

extern const unsi gned int sc_version_major ;
extern const unsi gned int sc_ver sion_minor ;
extern const unsi gned int sc_version_patch;
extern const std::stri ng sc_ver sion_originator;
extern const std::stri ng sc_version_release_date;
extern const std::stri ng sc_version_prerelease;
extern const bool sc_is_prerelease;
extern const std::stri ng sc_version_str ing;
extern const std::stri ng sc_copyr ight_string;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


412
Copyright 2012 IEEE. All rights reserved.
Each i mplementati on shall def ine the macros and constants given above. I t is recommended that
each implementati on shoul d i n addition def ine one or more i mplementation-speci fi c macros i n order
to all ow an appl ication to determine whi ch i mplementation is bei ng run.
The values of the macros and constants defi ned i n thi s clause may be independent of the values of
the corresponding set of def initions f or TLM-2.0 given i n 10.8.2.
Each i mpl ementati on-defi ned_number shall consi st of a sequence of deci mal di gits from the
character set [09] not enclosed in quotation marks.
The origi nator and pre-rel ease stri ngs shall each consi st of a sequence of characters f rom the
character set [AZ][az][09]_ enclosed in quotation marks.
The version rel ease date shall consist of an I SO 8601 basic f ormat calendar date of the form
YYYYMMDD, where each of the eight characters i s a deci mal digit, encl osed i n quotation marks.
The value of the SC_IS_PRERELEASE fl ag shal l be either 0 or 1, not enclosed i n quotati on marks.
The versi on stri ng shall be set to the value "major.minor.patch_prerel ease-ori ginator" or
"major.minor.patch-origi nator", where maj or, mi nor, patch, prerel ease, and origi nator are the values
of the corresponding strings (without enclosi ng quotati on marks), and the presence or absence of the
prerel ease string shall depend on the value of the SC_IS_PRERELEASE fl ag.
The copyri ght string should be set to a copyri ght notice. The intent i s that this string should contain
a legal copyri ght notice, whi ch an appli cati on may pri nt to the console window or to a log fi le.
Each constant shall be i nitiali zed with the val ue def ined by the macro of the corresponding name
converted to the appropri ate data type.
const char* sc_release();
The f unction sc_release shal l return the value of the sc_ver sion_str ing converted to a C stri ng.
const char* sc_version();
Function sc_version shal l return an i mplementati on-def ined stri ng. The intent i s that thi s stri ng
should contai n i nf ormation concerning the version of the SystemC cl ass l ibrary i mplementati on,
which an appl icati on may pri nt to the consol e window or to a l og f il e.
const char* sc_copyr ight();
The method sc_copyr ight shall return the value of the copyri ght stri ng converted to a C string.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


413
Copyright 2012 IEEE. All rights reserved.
9. Overview of TLM-2.0
The fol lowing cl auses def ine the OSCI Transaction-Level Modeli ng Standard, versi on 2.0, also known as
TLM-2.0. TLM-2.0 supersedes versions 2.0-draft-1 and 2.0-draf t-2, and i t is not general ly compati bl e wi th
either. Thi s version of the standard includes the core i nterf aces f rom TLM-1.
TLM-2.0 consists of a set of core interfaces, the gl obal quantum, initiator and target sockets, the generic
payl oad and base protocol , and the uti li ti es. The TLM-1 core i nterf aces, anal ysis i nterf ace, and anal ysi s
ports are also included, although they are separate f rom the mai n body of the TLM-2.0 standard. The TLM-
2.0 core i nterf aces consist of the blocki ng and non-blocki ng transport i nterf aces, the direct memory interface
(DMI ), and the debug transport interface. The generic payl oad supports the abstract model ing of memory-
mapped buses, together wi th an extensi on mechanism to support the modeli ng of speci fi c bus protocols
whil e maxi mizing interoperabil ity.
The TLM-2.0 cl asses are layered on top of the SystemC cl ass li brary as shown in Fi gure 16. For maximum
interoperabi li ty, and particularl y for memory-mapped bus modeli ng, it i s recommended that the TLM-2.0
core interfaces, sockets, generic payload, and base protocol be used together in concert. These cl asses are
known col lecti vel y as the i nter oper abi l i ty l ayer . I n cases where the generi c payl oad is i nappropriate, i t is
possibl e f or the core interfaces and the i nitiator and target sockets, or the core i nterfaces alone, to be used
wi th an al ternati ve transaction type. I t is even techni cal ly possi bl e f or the generic payload to be used di rectly
wi th the core i nterf aces wi thout the initiator and target sockets, although thi s approach is not recommended.
I t i s not strictl y necessary to use the util ities to achi eve interoperabi lity between bus models. Nonethel ess,
these cl asses should be used where possibl e for consistency of styl e and are documented and maintai ned as
part of the TLM-2.0 standard.
Figure 16TLM 2.0 Classes
The generic payload is primaril y i ntended for memory-mapped bus modeli ng, but it may also be used to
model other non-bus protocols with simi lar attributes. The attri butes and phases of the generi c payl oad can
be extended to model specif ic protocol s, but such extensions may lead to a reducti on in i nteroperabil ity
depending on the degree of devi ation from the standard non-extended generic payl oad.
TLM 2.0 Classes
I nter operabil ity layer
Generi c payload & base protocol
Initiator & target sockets
Gl obal quantum
TL M -2 cor e inter f aces:
Bl ocki ng transport interface
Non-blocking transport interface
Di rect memory interface
Debug transport i nterface
Ut ili ties:
Convenience sockets
Payload event queues
Quantum keeper
Instance-speci fic extensions
TL M -1:
TLM-1 core interfaces
tl m_fif o
Anal ysi s interf ace
Anal ysi s ports
SystemC
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


414
Copyright 2012 IEEE. All rights reserved.
A fast, l oosel y-timed model is typi call y expected to use the blocki ng transport interface, the direct memory
interface, and temporal decoupli ng. A more accurate, approximatel y-ti med model is typically expected to
use the non-bl ocki ng transport interface and the payload event queues. These statements are j ust codi ng
style suggestions, however, and are not a normative part of the TLM-2.0 standard.
9.1 Compliance with the TLM-2.0 standard
This standard defi nes three notions of compl iance related to the TLM-2.0 cl asses, the fi rst concerning
compliance of the i mplementati on and the l atter two concerning compliance of the appli cati on.
a) A TLM -2.0-compliant implementation is an impl ementation that provi des al l of the TLM-2.0
classes described in this standard wi th the semanti cs descri bed i n this standard, including both the
TLM-2.0 i nteroperabi li ty layer and the TLM-2.0 util ities. TLM-2.0-compli ance al one does not infer
f ul l compl iance with the entire standard, although i t does i mpli citl y i nfer compli ance wi th the subset
of SystemC used by the TLM-2.0 cl asses (see also 1.3).
b) A TLM -2.0 base-protocol-compliant model is a part of an appli cati on that obeys all of the rul es of
the TLM-2.0 base protocol as descri bed i n thi s standard. Such a model will necessaril y consist of
one or more SystemC modules with standar d sockets (as def ined below) speci al ized usi ng the
protocol trai ts class tlm_base_protocol, and preci sel y obeying each and every rul e def ined in 15.2.
See 15.2.1 for an i ntroducti on to the base protocol rul es and 14.2.1 regardi ng the use of extensi ons
wi th the base protocol .
c) A TLM -2.0 custom-protocol-compliant model is a part of an appl icati on that has standar d sockets
speciali zed with a user-defi ned protocol trai ts class (speci fi cal ly not tlm_base_protocol) and that
uses the generic payload, i ncl udi ng the generic payload extension and memory management
mechanisms where appropri ate. A custom-protocol-compliant model is not obli ged to obey any of
the rul es of the base protocol , al though such a model is recommended to f oll ow the rules of the base
protocol as cl osely as possi bl e in order to mini mi ze the amount of engineeri ng eff ort required to
interface any two such model s. Al though this recommendation is necessari ly inf ormal, there being
no a pr i or i li mits on the kinds of protocols modeled using TLM-2.0, i t is key to gaining benefi t from
the TLM-2.0 standard. See 14.2.2 regarding the relationshi p between custom protocol rul es and the
base protocol.
I n case b) and case c), the term standar d socket means an obj ect of type tlm_initiator _socket,
tlm_tar get_socket, or any class deri ved from one of these two cl asses.
A model that uses onl y i sol ated f eatures of the TLM-2.0 cl ass l ibrary may be compli ant with this standard
but is nei ther TLM-2.0 base-protocol-compl iant nor TLM-2.0 custom-protocol-compl iant.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


415
Copyright 2012 IEEE. All rights reserved.
10. Introduction to TLM-2.0
10.1 Background
The TLM-1 standard def ined a set of core interfaces for transporting transactions by value or const
ref erence. Thi s set of i nterf aces i s bei ng used successfull y i n some appl icati ons, but i t has three
shortcomings wi th respect to the modeli ng of memory-mapped buses and other on-chip communi cation
networks:
a) TLM-1 has no standard transaction class, so each applicati on has to create its own non-standard
classes, resul ti ng i n very poor interoperabi lity between model s f rom di f ferent sources. TLM-2.0
addresses thi s shortcomi ng wi th the generi c payload.
b) TLM-1 has no expl icit support f or timing annotation, so no standardized way of communicati ng
ti mi ng i nformation between models. TLM-2.0 addresses this shortcoming wi th the addition of
ti mi ng annotation function arguments to the bl ocking and non-bl ocki ng transport i nterf ace.
c) The TLM-1 i nterf aces requi re all transaction objects and data to be passed by value or const
ref erence, which may sl ow down si mulati on i n certai n use cases (al though not al l). TLM-2.0 passes
transaction objects by non-const ref erence, which is a f ast soluti on for model ing memory-mapped
buses.
10.2 Transaction-level modeling, use cases, and abstraction
There has been a l ongstanding discussi on in the ESL community concerning what is the most appropri ate
taxonomy of abstracti on l evels f or transaction-l evel model ing. Model s have been categorized accordi ng to a
range of cri teri a, including granul ari ty of time, f requency of model evaluati on, f uncti onal abstraction,
communi cation abstraction, and use cases. The TLM-2.0 activity expli ci tl y recognizes the existence of a
variety of use cases for transaction-level modeling, but rather than def ining an abstracti on l evel around each
use case, TLM-2.0 takes the approach of disti ngui shing between interf aces (API s), on the one hand, and
codi ng styl es, on the other. The TLM-2.0 standard defi nes a set of i nterf aces that shoul d be thought of as
low-level programming mechanisms f or i mpl ementing transaction-l evel model s, and then descri bes a
number of codi ng styles that are appropriate for, but not l ocked to, the vari ous use cases (Fi gure 17).
The def initions of the standard TLM-2.0 i nterf aces stand apart f rom the descri ptions of the coding styles. It
is the TLM-2.0 i nterf aces that f orm the normative part of the standard and ensure i nteroperabi li ty. Each cod-
ing style can support a range of abstracti on across functi onali ty, timing, and communicati on. In principl e
users can create their own coding styl es.
An unti med f unctional model consi sting of a single sof tware thread can be wri tten as a C function or as a
single SystemC process, and it is sometimes termed an al gori thmi c model. Such a model is not tr ansacti on-
l evel per se, because by def inition a transacti on is an abstraction of communicati on, and a si ngl e-threaded
model has no inter-process communicati on. A transacti on-level model requires multipl e SystemC processes
to simul ate concurrent executi on and communicati on.
An abstract transacti on-level model contai ning multiple processes (mul tipl e software threads) requires some
mechanism by whi ch those threads can yield control to one another. This is because SystemC uses a
cooperati ve multitasking model where an executing process cannot be pre-empted by any other process.
SystemC processes yield control by call ing wai t i n the case of a thread process, or returni ng to the kernel in
the case of a method process. Calls to wai t are usuall y hi dden behind a programmi ng i nterf ace (API), whi ch
may model a particul ar abstract or concrete protocol that may or may not rel y on ti mi ng inf ormati on.
Synchroni zati on may be str ong in the sense that the sequence of communi cation events i s precisely
determi ned in advance, or weak in the sense that the sequence of communi cation events is partial ly
determi ned by the detai led timi ng of the indivi dual processes. Strong sychroni zation i s easi ly i mpl emented
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


416
Copyright 2012 IEEE. All rights reserved.
in SystemC using FIFOs or semaphores, all owing a completel y unti med modeli ng styl e where in pri nci pl e
simul ation can run wi thout advancing simul ati on time. Unti med model ing i n thi s sense i s outsi de the scope
of TLM-2.0. On the other hand, a fast vi rtual platf orm model all owi ng multiple embedded software threads
to run in parallel may use ei ther strong or weak synchronizati on. In thi s standard, the appropriate coding
style for such a model is termed l oosel y-ti med.
A more detailed transacti on-l evel model may need to associ ate mul ti ple protocol -speci fi c timi ng points with
each transacti on, such as ti mi ng poi nts to mark the start and the end of each phase of the protocol . By
choosing an appropri ate number of timi ng poi nts, i t i s possi bl e to model communication to a hi gh degree of
ti mi ng accuracy without the need to execute the component model s on every single clock cycl e. In thi s
standard, such a coding style is termed appr oxi matel y-ti med.
Figure 17Use cases, coding styles, and mechanisms
10.3 Coding styles
A codi ng style is a set of programmi ng l anguage idioms that work well together, not a specif ic abstraction
level or sof tware programmi ng interface. For si mpli city and clari ty, thi s document restri cts i tsel f to
elaborati ng two speci fi c named codi ng styles: l oosel y-ti med and appr oxi matel y-ti med. By their nature the
codi ng styl es are not preci sely defi ned, and the rul es governi ng the TLM-2.0 core interfaces are defi ned
independently from these coding styl es. I n pri nci ple, i t would be possible to def ine other codi ng styles based
on the TLM-1 and TLM-2.0 mechanisms.
10.3.1 Untimed coding style
TLM-2.0 does not make expl icit provisi on f or an unti med codi ng styl e because all contemporary bus-based
systems requi re some noti on of ti me i n order to model software running on one or more embedded
processors. However, untimed model ing i s supported by the TLM-1 core interfaces. (The term unti med i s
sometimes used to ref er to models that contai n a l imi ted amount of timi ng inf ormati on of unspecif ied
accuracy. I n TLM-2.0, such models woul d be termed l oosel y-ti med.)
Software
development
Sof tware
performance
Archi tectural
analysis
Hardware
verif icati on
Non-blocking
interface
Phases
Generi c
payload
Sockets Quantum DMI
Bl ocki ng
interface
Mechanisms
Loosel y-timed
Approximately-ti med
TLM-2 Coding Styles Each style supports a range of abstractions
Use cases
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


417
Copyright 2012 IEEE. All rights reserved.
10.3.2 Loosely-timed coding style and temporal decoupling
The l oosely-timed codi ng style makes use of the blocking transport interface. This i nterf ace al lows onl y two
ti mi ng points to be associated with each transaction, corresponding to the call to and return from the
blocking transport f unction. I n the case of the base protocol , the first timing point marks the begi nni ng of the
request, and the second marks the beginning of the response. These two ti ming poi nts could occur at the
same simul ation ti me or at dif ferent times.
The loosely-ti med coding style i s appropriate f or the use case of software development using a vi rtual
platf orm model of an MPSoC, where the software content may include one or more operating systems. The
loosel y-timed coding styl e supports the model ing of ti mers and interrupts, suf fici ent to boot an operati ng
system and run arbitrary code on the target machine.
The l oosely-ti med coding style al so supports temporal decoupl i ng, where indivi dual SystemC processes are
permi tted to run ahead in a local time warp without actually advancing simul ation time until they reach the
point when they need to synchronize with the rest of the system. Temporal decoupling can resul t in very f ast
simul ation for certain systems because i t i ncreases the data and code l ocali ty and reduces the schedul ing
overhead of the si mulator. Each process i s all owed to run f or a certai n time sli ce or quantum bef ore
switchi ng to the next, or instead, i t may yi el d control when it reaches an expl ici t synchronizati on point.
Just consideri ng SystemC i tself , the SystemC scheduler keeps a tight hold on si mulation time. The scheduler
advances simul ation time to the ti me of the next event; then it runs any processes due to run at that time or
sensitive to that event. SystemC processes onl y run at the current simul ation ti me (as obtained by call ing the
method sc_time_stamp), and whenever a SystemC process reads or writes a variable, it accesses the state of
the variable as i t would be at the current simul ation ti me. When a process fi ni shes runni ng, i t must pass
control back to the simulation kernel. I f the si mulati on model i s wri tten at a f ine-grai ned l evel, then the
overhead of event schedul ing and process context switchi ng becomes the dominant f actor in si mulation
speed. One way to speed up simul ation i s to all ow processes to run ahead of the current simul ation time, or
temporal decoupl ing.
When i mplementi ng temporal decoupl ing i n SystemC, a process can be all owed to run ahead of si mulati on
ti me unti l i t needs to interact with another process, for example, to read or update a variable bel ongi ng to
another process. At that point, the process may ei ther access the current val ue and conti nue (wi th some
possibl e loss of ti mi ng accuracy) or may return control to the simul ati on kernel , only resumi ng the process
when simulation time has caught up with the local time warp. Each process is responsible for determining
whether it can run ahead of simul ation time without breaking the f uncti onal ity of the model . When a process
encounters an external dependency, it has two choices: Either f orce synchroni zation, whi ch means yieldi ng
to al low al l other processes to run as normal until simul ati on ti me catches up, or sampl e or update the current
val ue and continue. The synchroni zation option guarantees functi onal congruency wi th the standard
SystemC si mulation semanti cs. Conti nui ng wi th the current val ue reli es on maki ng assumptions concerning
communication and ti ming in the modeled system. It assumes that no damage will be done by sampl ing or
updating the val ue too early or too l ate. Thi s assumption i s usual ly vali d in the context of a virtual platform
simul ation, where the software stack shoul d not be dependent on the l ow-l evel detail s of the hardware
ti mi ng anyway.
Temporal decoupling is characteristi c of the l oosely-timed codi ng styl e.
I f a process were permitted to run ahead of simul ation time with no li mi t, the SystemC schedul er woul d be
unabl e to operate and other processes woul d never get the chance to execute. Thi s may be avoided by
ref erence to the gl obal quantum, which i mposes an upper l imi t on the ti me a process is al lowed to run ahead
of si mulati on ti me. The quantum is set by the appl icati on, and the quantum val ue represents a trade-off
between simul ation speed and accuracy. Too smal l a quantum forces processes to yi el d and synchronize
very frequently, slowing down si mulati on. Too large a quantum might i ntroduce timi ng i nconsi stenci es
across the system, possibly to the point where the system ceases to f uncti on.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


418
Copyright 2012 IEEE. All rights reserved.
For example, consi der the simul ation of a systemconsi sting of a processor, a memory, a ti mer, and some
slow external peripherals. The software runni ng on the processor spends most of i ts time fetchi ng and
executi ng instructions from system memory, and onl y i nteracts with the rest of the system when it i s
interrupted by theti mer, say every 1 ms. TheISSthat modelstheprocessor coul dbepermi tted torun ahead
of SystemCsimul ation ti mewi th aquantum of up to 1 ms, making di rect accessesto thememory model, but
only synchroni zi ng wi th theperi pheral models at therateof timer interrupts. Thepoint here is that theISS
does not haveto be locked to thesimul ation timecl ock of thehardwarepart of thesystem, as woul d bethe
case wi th more tradi ti onal hardware-software co-si mulati on. Dependi ng on the detai l of the models,
temporal decoupling al one could gi ve a si mulati on speed improvement of approximatel y 10X, or 100X,
whencombined withDMI.
It is qui tepossi blefor someprocessesto betemporall y decoupled and othersnot, and for di fferent processes
to usedi fferent valuesfor thetimequantum. However, any processthat i snot temporall y decoupled i sli kel y
to becomeasimulati onspeed bottl eneck.
In TLM-2.0, temporal decoupl ing i ssupported by thetlm_global_quantumcl ass and theti ming annotati on
of the blocki ng and non-bl ocking transport interface. The util ity cl ass tlm_quantumkeeper provi des a
convenient way to access thegl obal quantum.
10.3.3 Synchronization in loosely-timed models
An unti med model reli es on thepresenceof explici t synchronizati on points(that i scall sto wait or bl ocking
method cal ls) in order to pass control between initiators at predetermi ned points duri ng execution. A
loosel y-timed model can also benefit from expl ici t synchronization in order to guarantee determini stic
executi on, but a loosel y-ti med model is abl eto makeprogress even i n theabsence of expli cit synchroniza-
ti on points (call s to wait), becauseeach initiator wil l onl y run ahead as far as the end of the ti mequantum
before yieldi ng control . A loosel y-timed model can increasei ts timing accuracy by using synchronizati on-
on-demand, that i s, yiel di ngcontrol to thescheduler beforereaching theend of theti mequantum.
Theti mequantummechani sm i snot i ntended to ensurecorrect systemsynchroni zation, but it i sasimul ation
mechanism that al lows multipl e system initiators to make progress in a schedul er-based simul ation
envi ronment. The ti me quantummechani sm i s not an alternative to desi gni ng an expli ci t synchronization
schemeat thesystemlevel.
10.3.4 Approximately-timed coding style
The approximatel y-timed coding style is supported by the non-blocking transport i nterface, whi ch i s
appropriate for the use cases of archi tectural explorati on and performance analysis. The non-blocking
transport interface provi des for ti mi ng annotation and for mul tipl e phases and timing poi nts during the
li feti meof atransaction.
For approximatel y-timed modeling, a transaction is broken down i nto multipl e phases, with an expl icit
ti mi ng point marking the transition between phases. In the case of thebase protocol there are exactl y four
ti mi ng poi nts marki ng the begi nni ng and the end of the request and the beginning and the end of the
response. Specific protocol s may need to add further ti ming points, which may possi bl y cause the l oss of
direct compati bi li ty wi th thegeneri c payl oad.
Al though it i s possibl eto use thenon-blocking transport i nterfacewith just two phases to indicate thestart
and end of atransacti on, theblocking transport interfacei sgenerally preferred for l oosely-timed modeling.
Theapproximatel y-ti med coding stylecannot generall y exploi t temporal decoupli ng becauseof theneed for
ti mi ng accuracy. Instead, each process typicall y executes i n l ock step with the SystemC schedul er. Process
interactions are annotated wi th specific del ays. To create an approximatel y-ti med model, i t is generall y
suffi cient to annotate delays representi ng the data transfer ti mes for wri te and read commands and the
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


419
Copyright 2012 IEEE. All rights reserved.
latency of thetarget. For thebaseprotocol, thedatatransfer timesareeffectively thesameastheminimum
ini ti ation i nterval or accept del ay between two successi ve requests or two successive responses. The
annotated del ays are impl emented by making call s to the SystemC scheduler, that is, wait(delay) or
noti fy(delay).
10.3.5 Characterization of loosely-timed and approximately-timed coding styles
Thecoding styl escanbecharacteri zed in termsof timing poi ntsand temporal decoupli ng.
Loosely-ti med. Each transaction hasj ust two timi ngpoints, marki ngthestart and theend of thetransaction.
Simul ati on ti me is used, but processes may be temporall y decoupled from si mulati on time. Each process
keeps a tall y of how far it hasrun ahead of simul ation ti me, and it may yield becausei t reachesan expli ci t
synchronizati on point or becausei t hasconsumed i tstimequantum.
Approximately-timed. Each transacti onhasmul ti pl etimi ng points. Processestypicall y need to run in lock-
step wi th SystemC si mulati on time. Del ays annotated onto process i nteracti ons are i mplemented using
ti meouts(wait) or timed event noti fi cati ons.
Untimed. The notion of simul ation ti me is unnecessary. Processes yiel d at expl icit pre-determined
synchronization points.
10.3.6 Switching between loosely-timed and approximately-timed modeling
A model may switch between the l oosely-timed and approxi matel y-timed coding styl e duri ng simul ation.
The i dea i s to run rapi dl y through the reset and boot sequence at the l oosely-timed l evel, then switch to
approxi mately-ti med model ing for more detail ed analysis once the simul ation has reached an interesti ng
stage.
10.3.7 Cycle-accurate modeling
Cycle-accuratemodeli ng is beyond thescopeof TLM-2.0 at present. It is possible to createcycle-accurate
models using SystemC and TLM-1 as i t stands, but the requirement for the standardi zation of a cycle-
accurate coding style remai ns an open issue, possibly to be addressed by a future Accell era Systems
Ini ti ativestandard.
In pri nci ple onl y, the approxi mately-timed codi ng style mi ght be extended to encompass cycle-accurate
modeli ng by defi ni ng an appropri ate set of phases and rules. The TLM-2.0 release includes suffi cient
machi nery for this, but thedetail shavenot been worked out.
10.3.8 Blocking versus non-blocking transport interfaces
Thebl ocki ng and non-blocking transport i nterfacesaredisti nct interfaces that exist in TLM-2.0 to support
different level sof ti ming detail. Theblocking transport i nterfacei sonly ableto model thestart and end of a
transaction, with thetransacti on being compl eted wi thi n a single functi on cal l. The non-bl ocki ng transport
interfaceal lowsatransacti on to bebrokendown intomul ti pleti mi ng points, and typical ly requiresmul ti pl e
functi oncall sfor asingl etransaction.
For i nteroperabi li ty, theblocking and non-bl ocking transport i nterfacesarecombi ned into asi ngl ei nterface.
A model that i ni ti ates transacti ons may use the blocki ng or non-blocking transport interfaces (or both)
accordi ngtocoding style. Any model that provi desaTLM-2.0transport interfacei sobliged to provideboth
the bl ocki ng and non-bl ocki ng formsfor maxi mal interoperabil ity, although such amodel isnot obli ged to
impl ement bothi nterfaces internal ly.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


420
Copyright 2012 IEEE. All rights reserved.
TLM-2.0 provi des a mechanism (the so-cal led conveni ence socket) to automati cal ly convert incomi ng
blocking or non-blocki ng transport cal ls to non-blocking or blocki ng transport cal ls, respectively.
Converti ng transport cal l types doesincur somecost, particularl y converti ng an incoming non-blocki ng call
to a bl ocking i mplementati on. However, the cost overhead is mi ti gated by the fact that the presence of an
approxi mately-ti medmodel i sl ikely to haveanegativeimpact onsimul ati on speed anyway.
The C++ static typi ng rules enforce the impl ementation of both interfaces, but an ini ti ator can choose
dynami cal ly whether to cal l the bl ocki ng or the non-blocking transport method. It is possibl e for di fferent
ini ti atorstocal l different methods, or for agivenini ti ator to swi tch between blocki ngand non-bl ocki ng cal ls
on-the-fly. This standard i ncl udes rules governing the mixi ng and orderi ng of blocking and non-bl ocking
transport call sto thesametarget.
Thestrength of theblocking transport interfaceis that i t all owsasi mpli fi edcoding stylefor model sthat are
abl eto compl eteatransaction i n asinglefunction call. The strength of thenon-blocki ng transport interface
is that i t supports the associ ation of mul ti pl e ti mi ng poi nts wi th a single transacti on. In principle, either
interface supports temporal decoupli ng, but the speed benefits of temporal decoupling are l ikely to be
nulli fi edby thepresenceof multipl etimi ng poi ntsfor approxi mately-ti medmodels.
10.3.9 Use cases and coding styles
Tabl e52 summari zesthemapping between usecasesfor transaction-l evel modeli ngandcoding styl es:
10.4 Initiators, targets, sockets, and transaction bridges
The TLM-2.0 core interfaces pass transactions between initiators and targets (Fi gure18). An initiator i s a
module that can i nitiate transactions, that i s, create new transacti on objects and pass them on by cal li ng a
method of oneof thecoreinterfaces. A target i samodulethat acts asthefinal destinati onfor atransacti on.
Inthecaseof awritetransacti on, anini ti ator (such asaprocessor) writesdatato atarget (such asamemory).
Inthecaseof aread transacti on, an i nitiator readsdatafromatarget. An i nterconnect component isamodul e
that accesses a transaction but does not act as an initiator or a target for that transaction, typi cal examples
bei ng arbiters and routers. The roles of ini ti ator, interconnect, and target can change dynamicall y. For
exampl e, a gi ven component may act as an i nterconnect for some transacti ons but as a target for other
transactions.
Table 52Mapping between use cases for transaction-level modeling and coding styles
Use case Coding style
Softwareapplicationdevelopment Loosely-timed
Softwareperformanceanalysis Loosely-timed
Hardwarearchitectural analysis Loosely-timed or approximately-timed
Hardwareperformanceverification Approximately-timed or cycle-accurate
Hardwarefunctional verification Untimed (verification environment), loosely-timed or
approximately-timed
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


421
Copyright 2012 IEEE. All rights reserved.
Figure 18Initiators and targets
To i ll ustratetheidea, thisparagraph wi ll descri bethel ifetimeof atypi cal transacti on obj ect (Fi gure19). The
transaction object i screated by an ini ti ator and passed asan argument of amethod of thetransport interface
(bl ocki ng or non-blocking). That method is impl emented by an i nterconnect component such asan arbiter,
which may read attri butes of the transacti on obj ect before passing i t on to a further transport call . That
second transport method i s impl emented by a second interconnect component, such as a router, whi ch i n
turn passes on thetransaction throughathird transport call toatarget such asamemory, thefinal desti nation
for the transaction object. (The actual number of interconnect components wi ll vary from transaction to
transaction. There may be none.) Thi s sequence of method cal ls i s known as the for ward path. The
transacti on i sexecuted in thetarget, andthetransacti on object may bereturned to theini ti ator i n oneof two
ways, either carried wi th the return from the transport method call s as they unwi nd, known as the r eturn
path, or passed by maki ng expli cit transport method cal lson theopposi tepath from target back to ini ti ator,
knownasthebackward path. This choiceisdetermi ned by thereturn val uefromthenon-blocking transport
method. (Stri ctly speaki ng therearetwo return pathscorresponding to theforward and backward paths, but
themeani ngi susual ly clear fromthecontext.)
Initiator
socket
Initiator
socket
Target
socket
Target
socket
Forward
path
Forward
path
Backward
path
Backward
path
Initiator Target
Interconnect
component
Transaction
object
References to a single transaction
object are passed along the
forward and backward paths.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


422
Copyright 2012 IEEE. All rights reserved.
Figure 19TLM-2.0 connectivity
The forward path i s the call ing path by whi ch an initiator or interconnect component makes i nterf ace method
cal ls f orward in the di rection of another interconnect component or the target. The backward path i s the
cal li ng path by which a target or interconnect component makes interface method cal ls back in the directi on
of another i nterconnect component or the i ni ti ator. The entire path between an i nitiator and a target consi sts
of a number of hops, each hop connecting two adj acent components. A hop consists of one i niti ator socket
bound to one target socket. The number of hops f rom initiator to target is one greater than the number of
interconnect components on that path. When using the generi c payload, the f orward and backward paths
should each pass through the same set of components and sockets in opposing directi ons.
I n order to support both forward and backward paths, each connecti on between components requires a port
and an export, both of whi ch have to be bound. Thi s is f aci li tated by the i ni ti ator socket and the tar get
socket. An ini ti ator socket provi des a port for interface method calls on the f orward path, and an export f or
interface method call s on the backward path. A target socket provi des the opposi te. (More specif ically, an
ini ti ator socket is deri ved f rom cl ass sc_por t and has an sc_expor t, and vi ce versa f or a target socket.) The
ini ti ator and target socket classes overl oad the SystemC port bi ndi ng operator to bind impl icitly both
f orward and backward paths.
As well as the transport interf aces, the sockets also encapsulate the DMI and debug transport interf aces (see
bel ow).
When using sockets, an initiator component wil l have at least one initiator socket, a target component at
least one target socket, and an i nterconnect component at least one of each. A component may have several
sockets transporting dif ferent transacti on types, i n which case a si ngle component may act as an i niti ator or
as a target f or multipl e i ndependent transactions.
I n order to model a bus bridge, there are two alternatives. Either model the bus bri dge as an i nterconnect
component or model the bus bri dge as a transacti on bri dge between two separate TLM-2.0 transacti ons. An
interconnect component would pass on a poi nter to a si ngl e transaction object, whi ch is the best approach for
Initiator Target
Initiator
Interconnect
Target
component
Interconnect
component
Initiator
Initiator/
Target
Target
Initiator/
Target
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


423
Copyright 2012 IEEE. All rights reserved.
simul ation speed. A transaction bri dge woul d require the transaction object to be copied, which gi ves much
more f lexibil ity because the two transactions could have dif ferent attri butes.
The use of TLM-2.0 sockets i s recommended f or maxi mal interoperabi li ty, convenience, and a consi stent
codi ng styl e. Although i t i s possi ble for components to use SystemC ports and exports di rectl y with the
TLM-2.0 core interfaces, this is not recommended.
10.5 DMI and debug transport interfaces
The direct memory i nterf ace (DMI) and debug transport i nterface are speci al ized i nterf aces di stinct from the
transport interface, provi ding di rect access and debug access to an area of memory owned by a target. Once
a DMI request has been granted, the DMI interface enables an initiator to bypass the usual path through the
interconnect components used by the transport interface. DMI i s i ntended to accel erate regul ar memory
transactions in a l oosely-timed simulati on, whereas the debug transport interface i s for debug access f ree of
the del ays or side-eff ects associated with regular transactions.
The DMI has both forward (ini ti ator-to-target) and backward (target-to-initiator) interfaces, whereas debug
only has a f orward i nterface (see 11.2 and 11.3).
10.6 Combined interfaces and sockets
The blocking and non-blocking transport i nterf aces are combi ned wi th the DMI and debug transport
interfaces i n the standard ini ti ator and target sockets. Al l four interfaces (the two transport interfaces, DMI,
and debug) can be used i n paral lel to access a gi ven target (subject to the rul es described i n this standard).
These combi ned interf aces are one of the keys to ensuring i nteroperabili ty between components usi ng the
TLM-2.0 standard, the other key being the generi c payload (see 13.1).
The standard target sockets provi de al l four i nterf aces, so each target component must ef fecti vel y implement
the methods of all f our interf aces. However, the design of the blocki ng and non-bl ocki ng transport interfaces
together wi th the provi si on of conveni ence sockets to convert between the two means that a given target
need only impl ement ei ther the blocking or the non-blocking transport method, not both, according to the
speed and accuracy requirements of the model.
A given i ni ti ator may choose to call methods through any or all of the core interfaces, again according to the
speed and accuracy requirements. The coding styl es menti oned above help gui de the choi ce of an
appropriate set of interface f eatures. Typicall y, a l oosely-timed i ni ti ator wil l cal l blocking transport, DMI
and debug, whereas an approximatel y-ti med initi ator wi ll call non-blocki ng transport and debug.
10.7 Namespaces
The TLM-2.0 cl asses shall be declared i n two top-level C++ namespaces, tlm and tlm_utils. Parti cul ar
impl ementati ons of the TLM-2.0 cl asses may choose to nest further namespaces withi n these two
namespaces, but such nested namespaces shal l not be used in appl icati ons.
Namespace tlm contains the classes that compri se the i nteroperabil ity interface f or memory-mapped bus
model ing.
Namespace tlm_utils contai ns util ity classes that are not strictl y necessary f or i nteroperabil ity at the
interf ace between memory-mapped bus models but that are neverthel ess a proper part of the TLM-2.0
standard.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


424
Copyright 2012 IEEE. All rights reserved.
10.8 Header files and version numbers
Appli cati ons shoul d #incl ude the header fi le tlm, which shal l contain all of the publi c declarations f or the
TLM-2.0 i nteroperabi li ty l ayer. The header f il es tlm and tlm.h shal l be equi val ent in the sense that they
shal l i ncl ude precisely the same set of declarations and macros, and they may be used i nterchangeably. The
header f il e tlm.h is provided f or backward compatibi li ty with earli er versi ons of TLM-2.0 and may be
deprecated i n f uture versi ons of this standard. The TLM-2.0 utili ti es shall not be present i n the header f il es
tlm or tlm.h. Appl icati ons should al so expl icitly #include the header fi les f or any TLM-2.0 uti li ti es they
may wish to use, which shall be placed in a directory named tlm_utils. The precise fi le names for each of
these header f il es are def ined i n their respective cl auses i n thi s standard.
10.8.1 Software version information
The header f il es tlm and tlm.h shall include a set of macros, constants, and f uncti ons that provi de
inf ormati on concerni ng the version number of the TLM-2.0 software di stri bution. Appl ications may use
these macros and constants.
The value of the macros and constants def ined i n thi s clause may be independent of the values of the
corresponding set of def initions f or SystemC given i n 8.6.5.
10.8.2 Definitions
namespace tl m
{
#def ine TLM_VERSION_MAJOR i mpl ementati on-defi ned_number // For example, 2
#def ine TLM_VERSION_MINOR i mpl ementati on-defi ned_number // 0
#def ine TLM_VERSION_PATCH i mpl ementati on-defi ned_number // 1
#def ine TLM_VERSION_ORIGI NATOR i mpl ementati on-defi ned_str i ng // "OSCI"
#def ine TLM_VERSION_RELEASE_DATE i mpl ementati on-defi ned_date // "20090329"
#def ine TLM_VERSION_PRERELEASE i mpl ementati on-defi ned_str i ng // "beta"
#def ine TLM_IS_PRERELEASE i mpl ementati on-defi ned_bool // 1
#def ine TLM_VERSION i mpl ementati on-defi ned_str i ng
// "2.0.1_beta-OSCI"
#def ine TLM_COPYRI GHT i mpl ementati on-defi ned_str i ng
const unsi gned int tl m_versi on_maj or;
const unsi gned int tl m_versi on_minor;
const unsi gned int tl m_versi on_patch;
const std::stri ng tl m_versi on_originator;
const std::string tl m_version_release_date;
const std::string tl m_versi on_prerel ease;
const bool tl m_is_prerelease;
const std::string tl m_versi on_string;
const std::string tl m_copyri ght_stri ng;
inl ine const char* tl m_rel ease();
inl ine const char* tl m_versi on();
inl ine const char* tl m_copyri ght();
} // namespace tl m
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


425
Copyright 2012 IEEE. All rights reserved.
10.8.3 Rules
a) Each i mpl ementati on-defi ned_number shall consi st of a sequence of deci mal di gits from the
character set [09] not enclosed i n quotati on marks.
b) The origi nator and pre-rel ease strings shal l each consi st of a sequence of characters f rom the
character set [AZ][az][09]_ enclosed i n quotati on marks.
c) The versi on rel ease date shall consist of an I SO 8601 basic format cal endar date of the f orm
YYYYMMDD, where each of the eight characters i s a deci mal digit, encl osed i n quotation marks.
d) The TLM_IS_PRERELEASE f lag shall be either 0 or 1, not encl osed in quotation marks.
e) The versi on stri ng shall be set to the value "major.minor.patch_prerel ease-ori ginator" or
"major.minor.patch-origi nator", where maj or, mi nor, patch, prerel ease, and origi nator are the values
of the corresponding strings (without enclosi ng quotati on marks), and the presence or absence of the
prerel ease string shall depend on the value of the TLM_I S_PRERELEASE fl ag.
f ) The copyright string should be set to a copyright noti ce.
g) Each constant shall be i nitiali zed with the val ue def ined by the macro of the corresponding name
converted to the appropri ate data type.
h) The methods tlm_release and tlm_version shall each return the val ue of the version string
converted to a C string.
i ) The method tlm_copyr ight shal l return the value of the copyri ght stri ng converted to a C string.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


426
Copyright 2012 IEEE. All rights reserved.
11. TLM-2.0 core interfaces
I n addi tion to the core i nterf aces f rom TLM-1, TLM-2.0 adds blocking and non-blocking transport
interf aces, a di rect memory i nterf ace (DMI ), and a debug transport interface.
11.1 Transport interfaces
The transport i nterf aces are the primary interfaces used to transport transacti ons between initiators, targets,
and interconnect components. Both the bl ocki ng and non-blocking transport interfaces support timi ng
annotation and temporal decoupli ng, but onl y non-bl ocking transport supports multiple phases within the
li fetime of a transacti on. Blocking transport does not have an expl icit phase argument, and any associati on
between bl ocking transport and the phases of the non-bl ocking transport interface i s purel y noti onal . Onl y
the non-blocki ng transport method returns a value i ndicating whether or not the return path was used.
The transport interfaces and the generic payl oad were designed to be used together f or the fast, abstract
model ing of memory-mapped buses. The transport i nterf ace templates are speciali zed wi th the transaction
type all owing them to be used separately f rom the generic payl oad, although many of the i nteroperabil ity
benefi ts would be l ost.
The rul es governing memory management of the transacti on obj ect, transaction ordering, and the permitted
f uncti on calli ng sequence depend on the specifi c transacti on type passed as a template argument to the
transport i nterf ace, which in turn depends on the protocol trai ts class passed as a template argument to the
socket (i f a socket is used).
11.1.1 Blocking transport interface
11.1.1.1 Introduction
The TLM-2.0 bl ocki ng transport interf ace is intended to support the loosely-timed coding styl e. The bl ock-
ing transport i nterf ace is appropriate where an i ni ti ator wi shes to complete a transaction with a target duri ng
the course of a single f uncti on call , the only timing points of interest being those that mark the start and the
end of the transacti on.
The blocking transport i nterface onl y uses the f orward path from ini tiator to target.
The TLM-2.0 bl ocki ng transport interface has deli berate simil arities with the transport i nterf ace from TLM-
1, which is sti ll part of the TLM-2.0 standard, but the TLM-1 transport interface and the TLM-2.0 bl ocking
transport i nterf ace are not identi cal . I n particular, the new b_tr anspor t method has a single transaction
argument passed by non-const ref erence and a second argument to annotate ti ming, whereas the TLM-1
transpor t method takes a request as a si ngl e const ref erence request argument, has no ti mi ng annotati on,
and returns a response by val ue. TLM-1 assumes separate request and response objects passed by val ue (or
const ref erence), whereas TLM-2.0 assumes a si ngl e transacti on object passed by ref erence, whether using
the blocki ng or the non-blocki ng TLM-2.0 i nterf aces.
The b_tr ansport method has a timi ng annotation argument. Thi s si ngl e argument is used on both the cal l to
and the return from b_tr anspor t to i ndi cate the ti me of the start and end of the transaction, respectively,
rel ative to the current simul ation ti me.
11.1.1.2 Class definition
namespace tl m {
templ ate <typename TRANS = tl m_generi c_payl oad>
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


427
Copyright 2012 IEEE. All rights reserved.
class tlm_blocking_tr anspor t_if : publi c virtual sc_core::sc_interf ace {
publ ic:
virtual voi d b_tr ansport(TRANS& trans, sc_core::sc_ti me& t) = 0;
} ;
} // namespace tl m
11.1.1.3 The TRANS template argument
The i ntent is that thi s core interface may be used to transport transacti ons of any type. A specif ic transaction
type, tlm_gener ic_payload, i s provided to ease i nteroperabi li ty between models where the preci se detai ls of
the transaction attributes are less i mportant.
For maximum i nteroperabil ity, appl icati ons shoul d use the default transacti on type tlm_gener ic_payload
wi th the base protocol (see 15.2). In order to model speci fi c protocol s, appl ications may substitute thei r own
transaction type. Sockets that use interfaces speci al ized with di ff erent transaction types cannot be bound
together, providing compile-time checking but restri cti ng interoperabi li ty.
11.1.1.4 Rules
a) The b_tr anspor t method may call wait, directl y or indirectly.
b) The b_tr anspor t method shall not be cal led from a method process.
c) The i ni ti ator may reuse a transaction object from one call to the next and across call s to the transport
interf aces, DMI, and the debug transport interface.
d) The call to b_tr anspor t marks the fi rst ti ming poi nt of the transaction. The return f rom b_tr anspor t
marks the fi nal timing poi nt of the transaction.
e) The ti mi ng annotati on argument al lows the ti mi ng poi nts to be off set f rom the simulati on ti mes
(value returned by sc_time_stamp()) at whi ch the f uncti on call and return are executed.
f ) The call ee may modi fy or update the transaction object, subject to any constrai nts imposed by the
transaction class TRANS.
g) I t i s recommended that the transacti on obj ect should not contain timi ng information. Timing should
be annotated using the sc_time argument to b_tr anspor t.
h) Typical ly, an interconnect component shoul d pass the b_tr anspor t cal l along the f orward path f rom
ini ti ator to target. I n other words, the implementation of b_tr anspor t for the target socket of the
interconnect component may call the b_tr anspor t method of an i ni ti ator socket.
i) Whether or not the impl ementation of b_tr anspor t is permitted to call nb_tr ansport_fw depends
on the rul es associ ated wi th the protocol. For the base protocol, the conveni ence socket
simple_target_socket is abl e to make thi s conversi on automati cal ly (see 16.1.2).
j) The i mplementati on of b_tr anspor t shall not cal l nb_tr ansport_bw.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


428
Copyright 2012 IEEE. All rights reserved.
11.1.1.5 Message sequence chartblocking transport
The bl ocking transport method may return immedi atel y (that is, i n the current SystemC eval uati on phase) or
may yield control to the schedul er and only return to the ini ti ator at a later poi nt in simul ation ti me
(Fi gure 20). Al though the i ni ti ator thread may be blocked, another thread i n the ini tiator may be permi tted to
cal l b_tr anspor t bef ore the fi rst call has returned, depending on the protocol .
Figure 20Blocking transport
11.1.1.6 Message sequence charttemporal decoupling
A temporal ly decoupled i ni ti ator may run at a noti onal local time i n advance of the current simul ati on time,
in whi ch case i t shoul d pass a non-zero value f or the ti me argument to b_tr anspor t, as shown below. The
ini ti ator and target may each f urther advance the local time of fset by i ncreasing the val ue of the time
argument. Addi ng the time argument returned f rom the cal l to the current si mulati on time gives the notional
ti me at whi ch each the transaction compl etes, but simul ati on time itself cannot advance unti l the initiator
thread yields.
The body of b_tr anspor t may itsel f call wait, in whi ch case the l ocal time off set should be reset to zero. In
Figure 21, the f inal return f rom the i ni ti ator happens at si mulati on ti me 140 ns, but with an annotated delay
of 5 ns, givi ng an ef fective local ti me of 145 ns.
I nitiator Tar get
Cal l
Retur n
b_transport(t, 0ns);
b_transport(t, 0ns);
Cal l b_transport(t, 0ns);
Retur n
b_transport(t, 0ns);
wai t (40ns)
Simulation time = 100ns
Simulation time = 140ns
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


429
Copyright 2012 IEEE. All rights reserved.
Figure 21Temporal decoupling
11.1.1.7 Message sequence chartthe time quantum
A temporal ly decoupled initiator wil l conti nue to advance l ocal time unti l the ti me quantum i s exceeded
(Fi gure 22). At that poi nt, the initiator is obli ged to synchronize by suspendi ng execution, di rectl y or
indirectly cal li ng the wait method wi th the l ocal ti me as an argument. This all ows other ini tiators i n the
model to run and to catch up, whi ch eff ectivel y means that the initiators execute in turn, each being
responsibl e for determi ning when to hand back control by keepi ng track of its own l ocal ti me. The ori gi nal
ini ti ator should only run agai n af ter simul ation ti me has advanced to the next quantum.
The primary purpose of delays i n the loosely-timed codi ng styl e i s to al low each ini ti ator to determine when
to hand back control. It i s best i f the model does not rel y on the detail s of the ti ming in order to function cor-
rectl y.
Wi thi n each quantum, the transacti ons generated by a given ini ti ator happen in stri ct sequential order but
wi thout advanci ng simul ati on ti me. The local ti me is not tracked by the SystemC schedul er.
I nitiator Tar get
Cal l
Retur n
b_transport(t, 0ns);
b_transport(t, 5ns);
Cal l b_transport(t, 30ns);
Retur n b_transport(t, 5ns);
wai t (40ns)
Simulation time = 100ns
Simulation time = 140ns
+0ns
+5ns
Cal l
Retur n
b_transport(t, 20ns);
b_transport(t, 25ns);
+20ns
+25ns
+30ns
+5ns
Local time offset
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


430
Copyright 2012 IEEE. All rights reserved.
Figure 22The time quantum
11.1.2 Non-blocking transport interface
11.1.2.1 Introduction
The non-bl ocki ng transport i nterf ace i s intended to support the approxi matel y-ti med codi ng styl e. The non-
blocking transport interface is appropriate where i t i s desired to model the detai led sequence of interactions
between ini tiator and target during the course of each transaction. I n other words, to break down a transac-
ti on i nto multiple phases, where each phase transition is associ ated wi th a timi ng point. Each call to and
return from the non-bl ocki ng transport method may correspond to a phase transition.
By restricti ng the number of ti ming points to two, it is possi ble to use the non-bl ocking transport i nterf ace
wi th the l oosely-timed coding style, but this i s not general ly recommended. For l oosely-timed model ing, the
blocking transport i nterf ace i s generall y pref erred f or its si mpli ci ty. The non-blocking transport i nterf ace i s
parti cul arly suited f or modeli ng pi peli ned transacti ons, whi ch woul d be awkward to model using blocki ng
transport.
The non-blocki ng transport interface uses both the forward path f rom initiator to target and the backward
path from target to initiator. There are two disti nct interfaces, tlm_fw_nonblocking_tr ansport_if and
tlm_bw_nonblocking_tr anspor t_if, for use on opposite paths.
The non-blocking transport interface uses a si mil ar argument-passi ng mechanism to the bl ocking transport
interf ace in that the non-bl ocking transport methods pass a non-const ref erence to the transaction obj ect and
a ti ming annotation, but there the simil arity ends. The non-blocki ng transport method al so passes a phase to
indicate the state of the transacti on, and i t returns an enumeration value to i ndi cate whether the return from
the functi on also represents a phase transi tion.
Both blocki ng and non-blocki ng transport support timi ng annotation, but only non-blocking transport
supports multipl e phases wi thi n the lif etime of a transacti on. The blocki ng and non-bl ocki ng transport
I nitiator Tar get
Cal l
Retur n
b_transport(t, 950ns);
b_transport(t, 970ns);
Cal l
b_transport(t, 0ns);
wait (1010ns)
Simulation time = 1us
Simulation ti me = 2010ns
+950ns
+970ns
Cal l
Retur n
b_transport(t, 990ns);
b_transport(t, 1010ns);
+990ns
+1010ns
+0ns
Local time offset
Quantum = 1us
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


431
Copyright 2012 IEEE. All rights reserved.
interface and the generi c payl oad were desi gned to be used together for the f ast, abstract model ing of
memory-mapped buses. However, the transport interfaces can be used separately from the generic payl oad
to model speci fi c protocols. Both the transaction type and the phase type are template parameters of the non-
blocking transport interface.
11.1.2.2 Class definition
namespace tl m {
enum tlm_sync_enum { TLM_ACCEPTED, TLM_UPDATED, TLM_COMPLETED } ;
templ ate <typename TRANS = tlm_generic_payl oad, typename PHASE = tl m_phase>
class tlm_fw_nonblocking_tr anspor t_if : publ ic virtual sc_core::sc_interface {
publ ic:
virtual tl m_sync_enum nb_tr ansport_fw(TRANS& trans, PHASE& phase, sc_core::sc_ti me& t) = 0;
} ;
templ ate <typename TRANS = tlm_generic_payl oad, typename PHASE = tl m_phase>
class tlm_bw_nonblocking_transpor t_if : publ ic virtual sc_core::sc_interface {
publ ic:
virtual tl m_sync_enum nb_tr ansport_bw(TRANS& trans, PHASE& phase, sc_core::sc_time& t) = 0;
} ;
} // namespace tl m
11.1.2.3 The TRANS and PHASE template arguments
The intent is that the non-blocki ng transport interf ace may be used to transport transacti ons of any type and
wi th any number of phases and ti ming points. A specif ic transaction type, tlm_gener ic_payload, is
provided to ease interoperabil ity between model s where the precise detai ls of the transaction attributes are
less i mportant, and a specif ic type tlm_phase is provided f or use wi th the base protocol (see 15.2).
For maximum i nteroperabil ity, appl icati ons shoul d use the default transacti on type tlm_gener ic_payload
and the default phase type tlm_phase wi th the base protocol. I n order to model speci fi c protocol s,
appl icati ons may substitutethei r own transacti on type and phase type. Socketsthat use i nterf aces special ized
wi th dif ferent transacti on types cannot be bound together, providing compi le-ti me checki ng but restri cting
interoperabi li ty.
11.1.2.4 The nb_transport_fw and nb_transport_bw calls
a) There are two non-bl ocki ng transport methods, nb_tr ansport_fw for use on the f orward path, and
nb_tr anspor t_bw f or use on the backward path. Aside from their names and cal li ng di rection these
two methods have simi lar semanti cs. I n thi s document, the ital icized term nb_transpor t i s used to
descri be both methods i n situations where there i s no need to di stinguish between them.
b) I n the case of the base protocol , the forward and backward paths shoul d pass through exactl y the
same sequence of components and sockets i n opposing order. I t is the responsibil ity of each
component to route any transacti on returni ng toward the i ni ti ator using the target socket through
which that transacti on was fi rst received.
c) nb_tr anspor t_fw shall only be call ed on the forward path, and nb_tr ansport_bw shal l onl y be
cal led on the backward path.
d) An nb_tr anspor t_fw cal l on the forward path shal l under no ci rcumstances di rectly or indi rectly
make a cal l to nb_tr ansport_bw on the backward path, and vice versa.
e) The nb_transpor t methods shal l not cal l wait, directl y or indirectly.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


432
Copyright 2012 IEEE. All rights reserved.
f ) The nb_transpor t methods may be call ed f rom a thread process or from a method process.
g) nb_transpor t i s not permi tted to call b_tr anspor t. One soluti on woul d be to call b_tr anspor t f rom
a separate thread process, spawned or notif ied by the origi nal nb_tr anspor t_fw method. For the
base protocol, a conveni ence socket simple_target_socket i s provi ded, which is abl e to make this
conversion automaticall y (see 16.1.2).
h) The non-blocki ng transport i nterf ace is expli ci tl y i ntended to support pi pel ined transactions. In other
words, several successive call s to nb_tr ansport_fw from the same process coul d each ini ti ate
separate transactions without having to wai t for the f irst transaction to compl ete.
i ) I n principl e, the fi nal ti mi ng point of a transacti on may be marked by a call to or a return f rom
nb_transpor t on ei ther the forward path or the backward path.
11.1.2.5 The trans argument
a) The l if etime of a given transacti on object may extend beyond the return f rom nb_transpor t such that
a seri es of cal ls to nb_transpor t may pass a si ngl e transaction obj ect forward and backward between
ini ti ators, interconnect components, and targets.
b) If there are mul ti ple call s to nb_transpor t associ ated wi th a given transacti on i nstance, one and the
same transacti on obj ect shall be passed as an argument to every such call . In other words, a given
transaction instance shal l be represented by a single transacti on obj ect.
c) An initiator may re-use a gi ven transaction object to represent more than one transaction i nstance, or
across cal ls to the transport i nterf aces, DMI, and the debug transport i nterf ace.
d) Since the li fetime of the transaction object may extend over several call s to nb_transpor t, either the
cal ler or the call ee may modif y or update the transaction object, subj ect to any constrai nts imposed
by the transacti on class TRANS. For exampl e, for the generic payload, the target may update the
data array of the transaction obj ect i n the case of a read command but shal l not update the command
f ield (see 14.7).
11.1.2.6 The phase argument
a) Each cal l to nb_transpor t passes a ref erence to a phase object. In the case of the base protocol ,
successive call s to nb_transpor t wi th the same phase are not permitted. Each phase transi tion has an
associ ated timi ng point. A timi ng annotation usi ng the sc_time argument shall delay the timi ng
point rel ative to the phase transi ti on.
b) The phase argument is passed by reference. Either call er or call ee may modi fy the phase.
c) The intent is that the phase argument should be used to inform components as to whether and when
they are permi tted to read or modi fy the attri butes of a transacti on. I f the rul es of a protocol all ow a
given component to modif y the val ue of a transacti on attri bute during a parti cul ar phase, then that
component may modi fy the value at any ti me during that phase and any number of times during that
phase. The protocol should forbid other components from reading the value of that attri bute duri ng
that phase, onl y permi tting the val ue to be read after the next phase transi ti on.
d) The val ue of the phase argument represents the current state of the protocol state machi ne for the
given hop. Where a si ngl e transacti on object i s passed between more than two components (initiator,
interconnect, target), each hop requires (noti onall y, at least) a separate protocol state machi ne.
e) Whereas the transaction object has a li feti me and a scope that may extend beyond any si ngl e cal l to
nb_transpor t, the phase obj ect is normall y local to the cal ler. Each nb_tr anspor t cal l f or a given
transaction may have a separate phase object. Corresponding phase transi ti ons on di ff erent hops
may occur at dif ferent points i n simul ation ti me.
f ) The def aul t phase type tlm_phase i s specif ic to the base protocol . Other protocols may use or extend
type tlm_phase or may substi tute thei r own phase type (with a correspondi ng l oss of
interoperabi li ty) (see 15.1).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


433
Copyright 2012 IEEE. All rights reserved.
11.1.2.7 The tlm_sync_enum return value
a) The concept of sychroni zati on i s ref erred to in several places. To synchroni ze is to yi eld control to
the SystemC scheduler in order that other processes may run, but it has additional connotations f or
temporal decoupli ng. Thi s i s discussed more ful ly el sewhere (see 16.2.4).
b) In pri nci ple, synchroni zation can be accompli shed by yiel di ng (cal li ng wait in the case of a thread
process or returni ng to the kernel in the case of a method process), but a temporall y decoupled
ini ti ator should synchronize by call ing the sync method of cl ass tlm_quantumkeeper . In general , i t
is necessary f or an initiator to synchronize f rom time-to-ti me in order to all ow other SystemC
processes to run.
c) The f oll owing rules apply to both the forward and backward paths.
d) The meani ng of the return val ue from nb_transpor t is f ixed and does not vary according to the trans-
action type or phase type. Hence the foll owing rul es are not restricted to the base protocol but appl y
to every transacti on and phase type used to parameteri ze the non-bl ocki ng transport interface.
e) TLM _ACCEPTED. The cal lee shal l not have modif ied the state of the transacti on obj ect, the
phase, or the ti me argument during the cal l. In other words, TLM_ACCEPTED indicates that the
return path i s not being used. The cal ler may ignore the val ues of the nb_transpor t arguments
f ol lowi ng the call , since the cal lee is obli ged to leave them unchanged. I n general, the cal ler wil l
have to yi el d before the component containing the cal lee can respond to the transaction. For the base
protocol, a cal lee that is ignoring an i gnorabl e phase should return TLM_ACCEPTED.
f ) TLM _UPDATED. The cal lee has updated the transaction obj ect. The cal l ee may have modi fi ed the
state of the phase argument, may have modi fi ed the state of the transaction obj ect, and may have
increased the value of the ti me argument during the cal l. In other words, TLM_UPDATED indicates
that the return path i s bei ng used, and the cal lee has advanced the state of the protocol state machine
associ ated with the transaction. Whether or not the call ee is actual ly obl iged to modi fy each of the
arguments depends on the protocol . Fol lowing the cal l to nb_transpor t, the cal ler shoul d inspect the
phase, transacti on, and time arguments and take the appropri ate acti on.
g) TLM _COM PLETED. The callee has updated the transaction obj ect, and the transacti on i s
complete. The callee may have modi fi ed the state of the transacti on obj ect and may have i ncreased
the val ue of the ti me argument during the call . The value of the phase argument i s undefi ned. In
other words, TLM_COMPLETED indicates that the return path is being used and the transacti on is
complete with respect to a particular socket. Fol lowi ng the call to nb_transpor t, the cal ler shoul d
inspect the transaction object and take the appropri ate action but shoul d ignore the phase argument.
There shall be no f urther transport cal ls associated wi th thi s particular transaction through the
current socket al ong either the f orward or backward paths. Completion in thi s sense does not
necessari ly impl y successful completi on, so depending on the transacti on type, the cal ler may need
to i nspect a response status embedded i n the transaction obj ect.
h) I n general there is no obli gation to complete a transaction by havi ng nb_transpor t return
TLM_COMPLETED. A transaction is in any case complete with respect to a particular socket when
the f inal phase of the protocol i s passed as an argument to nb_tr anspor t. (For the base protocol, the
f inal phase i s END_RESP.) I n other words, TLM_COMPLETED i s not mandatory.
i ) For any of the three return val ues, and dependi ng on the protocol , f oll owing the call to nb_transpor t
the call er may need to yi el d in order to all ow the component containing the call ee to generate a
response or to rel ease the transaction obj ect.
11.1.2.8 tlm_sync_enum summary
Tabl e 53 provides a summary of tl m_sync_enum.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


434
Copyright 2012 IEEE. All rights reserved.
11.1.2.9 Message sequence chartusing the backward path
The foll owing message sequence charts i ll ustrate vari ous cal li ng sequences to nb_transpor t. The arguments
and return value passed to and f rom nb_transpor t are shown using the notation r eturn, phase, del ay, where
return is the val ue returned f rom the f unction call , phase is the val ue of the phase argument, and delay i s the
val ue of the sc_time argument. The notati on '-' indicates that the value is unused.
The f oll owi ng message sequence charts use the phases of the base protocol as an example, that is,
BEGI N_REQ, END_REQ and so on. With the approxi matel y-ti med codi ng style and the base protocol , a
transaction i s passed back-and-f orth twi ce between initiator and target. For other protocol s, the number of
phases and thei r names may be dif ferent.
I f the reci pi ent of an nb_transpor t cal l is unable immedi ately to calculate the next state of the transaction or
the delay to the next ti mi ng poi nt, i t should return a value of TLM_ACCEPTED. The call er shoul d yi el d
control to the schedul er and expect to receive a call to nb_transpor t on the opposi te path when the cal lee is
ready to respond. Notice that in this case, unl ike the l oosely-timed case, the caller could be the i niti ator or
the target (Figure 23).
Transacti ons may be pipeli ned. The ini ti ator could cal l nb_transpor t to send another transaction to the target
bef ore havi ng seen the fi nal phase transi tion of the previous transacti on.
Because processes are regularl y yi el ding control to the scheduler in order to allow simul ation ti me to
advance, the approximatel y-ti med codi ng styl e i s expected to si mulate a l ot more slowl y than the loosely-
ti med coding style.
Table 53tlm_sync_enum summary
tlm_sync_enum Unmodified Unchanged Unchanged
TLM_ACCEPTED Unmodi f ied Unchanged Unchanged
TLM_UPDATED Updated Changed May be i ncreased
TLM_COMPLETED Updated I gnored May be i ncreased
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


435
Copyright 2012 IEEE. All rights reserved.
Figure 23Using the backward path
11.1.2.10 Message sequence chartusing the return path
I f the recipient of an nb_transpor t call can immedi atel y calculate the next state of the transacti on and the
del ay to the next ti mi ng poi nt, it may return the new state on return from nb_transpor t rather than usi ng the
opposite path. I f the next timi ng point marks the end of the transacti on, the reci pient can return either
TLM_UPDATED or TLM_COMPLETED. A cal lee can return TLM_COMPLETED at any stage (subj ect
to the rules of the protocol) to indicate to the caller that i t has pre-empted the other phases and j umped to the
f inal phase, completi ng the transaction. This appli es to i ni ti ator and target ali ke.
Wi th TLM_UPDATED, the call ee should update the transaction, the phase, and the ti ming annotation.
I n Figure 24, the non-zero timi ng annotati on argument passed on return from the functi on call s indi cates to
the cal ler the delay between the phase transition on the hop and the correspondi ng timi ng poi nt.
I nitiator Tar get
Cal l
Retur n
-, BEGIN_REQ, 0ns
Cal l -, BEGIN_RESP, 0ns
Retur n
Simulation time= 100ns
Simulation time= 130ns
Cal l
Retur n
-, END_REQ, 0ns
TLM_ACCEPTED, -, -
TLM_ACCEPTED, -, -
Retur n TLM_ACCEPTED, -, -
-, END_RESP, 0ns
TLM_ACCEPTED, -, -
Cal l
Simulation time= 110ns
Simulation time= 120ns
Phase
BEGI N_REQ
END_REQ
BEGI N_RESP
END_RESP
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


436
Copyright 2012 IEEE. All rights reserved.
Figure 24Using the return path
11.1.2.11 Message sequence chartearly completion
Depending on the protocol , an initiator or a target may return TLM_COMPLETED from nb_transpor t at
any poi nt in order to compl ete the transacti on early. Neither ini ti ator nor target may make any f urther
nb_transpor t cal ls for this particular transacti on instance. Whether or not an i ni ti ator or target is actuall y
permi tted to shortcut a transacti on i n this way depends on the rul es of the specif ic protocol .
I n Figure 25, the ti ming annotati on on the return path i ndi cates to the i ni ti ator that the f inal timi ng point is to
occur af ter the given del ay. The phase transitions f rom BEGIN_REQ through END_REQ and
BEGI N_RESP to END_RESP are i mpli ci t, rather than being passed expl icitly as arguments to nb_transport.
I nitiator Tar get
Simul ation ti me = 110ns
Cal l
TLM_UPDATED, END_REQ, 10ns
-, BEGI N_REQ, 0ns
Retur n
Simul ation ti me= 100ns
BEGI N_REQ
END_REQ
Phase
Simulation time= 150ns
Simulation time= 155ns
Cal l
Retur n
BEGI N_RESP
END_RESP
-, BEGI N_RESP, 0ns
TLM_UPDATED, END_RESP, 5ns
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


437
Copyright 2012 IEEE. All rights reserved.
.
Figure 25Early completion
11.1.2.12 Message sequence charttiming annotation
A cal ler may annotate a del ay onto an nb_transpor t call (Figure 26). This i s an indi cati on to the call ee that
the transaction should be processed as i f it had been received af ter the gi ven delay. An approximatel y-timed
cal lee woul d typicall y handle thi s si tuati on by putting the transaction into a payload event queue f or
processing when simul ation ti me has caught up wi th the annotated del ay. Depending on the i mplementati on
of the payl oad event queue, thi s processi ng may occur ei ther i n a SystemC process sensi ti ve to an event
noti fi cati on f rom the payl oad event queue or i n a cal lback regi stered wi th the payl oad event queue.
Delays can be annotated onto call s on the f orward and backward paths and the corresponding return paths.
An approximatel y-timed i ni ti ator would be expected to handle incoming transactions on both the forward
return path and the backward path i n the same way. Similarly, an approximatel y-timed target woul d be
expected to handl e i ncomi ng transactions on both the backward return path and the forward path in the same
way.
I nitiator Tar get
Simulation ti me = 110ns
Cal l
TLM_COMPLETED, -, 10ns
-, BEGI N_REQ, 0ns
Retur n
Simulation time= 100ns
BEGI N_REQ
(END_RESP)
Phase
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


438
Copyright 2012 IEEE. All rights reserved.
Figure 26Timing annotation
11.1.3 Timing annotation with the transport interfaces
Timing annotati on is a shared f eature of the blocking and non-blocking transport i nterfaces, expressed usi ng
the sc_time argument to the b_tr anspor t, nb_tr ansport_fw, and nb_tr ansport_bw methods. I n this
document, the ital icized term tr ansport is used to denote the three methods b_tr anspor t, nb_tr ansport_fw,
and nb_tr anspor t_bw.
Transaction ordering i s governed by a combination of the core i nterf ace rul es and the protocol rules. The
rul es i n the f oll owi ng cl ause apply to the core interfaces regardl ess of the choi ce of protocol . For the base
protocol, the rul es given here should be read in conj unction with those in 15.2.7.
11.1.3.1 The sc_time argument
a) I t i s recommended that the transaction object should not contai n timing informati on. Any ti mi ng
annotation should be expressed using the sc_time argument to tr ansport.
b) The ti me argument shall be non-negati ve and shall be expressed relati ve to the current si mulati on
ti me sc_time_stamp().
I nitiator Tar get
Cal l
TLM_ACCEPTED, -, -
-, BEGI N_REQ, 10ns
Retur n
Simulation time= 100ns
BEGI N_REQ
END_REQ
Phase
Simulation ti me = 110ns
Simulation time= 125ns
Cal l
Retur n
-, END_REQ, 10ns
TLM_ACCEPTED, -, -
Simulation time= 135ns
Payl oad
Event
Queue
Payload
Event
Queue
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


439
Copyright 2012 IEEE. All rights reserved.
c) The ti me argument shall appl y on both the call to and the return from tr anspor t (subject to the rul es
of the tlm_sync_enum return value of nb_transpor t).
d) The nb_transpor t method may itself i ncrease the val ue of the time argument but shal l not decrease
the value. The b_tr anspor t method may i ncrease the value of the time argument or may decrease
the value in the case that it has call ed wait and thus synchroni zed wi th simul ation time, but only by
an amount that is less than or equal to the ti me for whi ch the process was suspended. This rul e is
consistent wi th ti me not running backward in a SystemC simul ation.
e) I n the fol lowing description, the r eci pi ent of the transacti on on the cal l to tr ansport is the callee, and
the r eci pi ent of the transaction on return from tr ansport is the call er.
f ) The r eci pi ent shall behave as i f i t had received the transaction at an eff ective l ocal time of
sc_time_stamp() + t, where t is the value of the time argument. In other words, the reci pient shall
behave as if the ti mi ng poi nt associated with the i nterf ace method cal l is to occur at the ef fecti ve
local ti me.
g) Gi ven a sequence of call s to tr ansport, the ef fecti ve l ocal times at which the transactions are to be
processed may or may not be in increasi ng time order i n general . For transacti ons created by
dif ferent initiators, i t is f undamental to temporal decoupl ing that interface method call order may be
dif ferent from eff ective local ti me order. The responsibi li ty to handle transactions with out-of-order
ti mi ng annotations l ies with the r eci pi ent.
h) On receipt of a transacti on with a non-zero timi ng annotation, any reci pi ent always has choi ces that
ref lect the modeli ng trade-off between speed and accuracy. The recipi ent can execute any state
changes caused by the transacti on immedi ately and pass on the ti ming annotation, possi bl y
increased, or it can schedul e some i nternal process to resume af ter part or all of the annotated time
has elapsed and execute the state changes onl y then. The choice is not enforced by the transport
interface but may be documented as part of a protocol trai ts class or coding styl e.
i) I f the recipi ent i s not concerned with timi ng accuracy or wi th processing a sequence of incoming
transactions i n the order given by their timi ng annotations, i t may process each transaction
immediately, without del ay. Havi ng done so, the reci pient may al so choose to i ncrease the val ue of
the ti ming annotati on to model the time needed to process the transaction. Thi s scenari o assumes
that the system desi gn can tol erate out-of-order execution because of the exi stence of some expli ci t
mechanism (over and above the TLM-2.0 i nterf aces) to enf orce the correct causal chain of events.
j) I f the recipient is to impl ement an accurate model of ti mi ng and executi on order, it should ensure
that the transaction is i ndeed processed at the correct ti me relati ve to any other SystemC processes
wi th whi ch i t may interact. I n SystemC, the appropriate mechani sm to schedul e an event at a f uture
ti me i s the ti med event notif icati on. For convenience, TLM-2.0 provides a fami ly of util ity classes,
known as payl oad event queues, which can be used to queue transactions for processi ng at the
proper simul ation ti me according to the natural semanti cs of SystemC (see 16.3). I n other words, an
approxi mately-ti med reci pi ent should typicall y put the transaction into a payl oad event queue.
k) Rather than processing the transacti on directly, the recipi ent may pass the transacti on on wi th a
f urther call to or return from a tr ansport method without modif ication to the transaction and usi ng
the same phase and timing annotati on (or with an increased ti mi ng annotation).
l ) Wi th the l oosely-timed codi ng style, transactions are typi cal ly executed immedi atel y such that
executi on order matches interface method call order, and the b_tr anspor t method i s recommended.
m) Wi th the approximatel y-timed codi ng style, transacti ons are typicall y del ayed such that thei r execu-
ti on order matches the ef fecti ve local time order, and the nb_transpor t method is recommended.
n) Each component can make the above choi ce dynamicall y on a call -by-call basi s. For example, a
loosel y-ti med component may execute a series of transactions immediatel y in cal l order, passi ng on
the ti mi ng annotations but may then choose to schedule the very next transacti on f or executi on only
after the del ay given by the timing annotati on has elapsed (known as synchroni zati on on demand).
This is a matter of coding style.
o) The above choice exi sts f or both blocking and non-blocki ng transport. For example, b_tr anspor t
may increase the timing annotati on and return immedi ately or may wait for the timing annotati on to
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


440
Copyright 2012 IEEE. All rights reserved.
elapse before returning. nb_transpor t may increase the ti mi ng annotati on and return
TLM_COMPLETED or may return TLM_ACCEPTED and schedul e the transacti on f or executi on
later.
p) As a consequence of the above rules, if a component i s the reci pient of a series of transacti ons where
the order of the i ncomi ng interface method calls is dif ferent f rom the eff ecti ve local time order, the
component is free to choose the mutual executi on order of those particular transactions. The
recommendation is to execute al l transacti ons i n cal l order or to execute al l transacti ons in ef fecti ve
local ti me order, but this is not an obli gation.
q) Note that the order in whi ch incoming transacti ons are executed by a component shoul d i n effect
always be the same as i nterf ace method cal l order because a component wi ll ei ther execute an
incoming transacti on bef ore returning f rom the i nterf ace method call regardl ess of the timi ng
annotation (l oosely-ti med), or will schedul e the transaction f or executi on at the proper f uture time
and return TLM_ACCEPTED (approxi mately-timed), thus i ndi cating to the call er that i t should wai t
bef ore i ssuing the next transacti on. (TLM_ACCEPTED alone does not forbid the cal ler from i ssuing
the next transacti on, but i n the case of the base protocol, the request and response exclusi on rul es
may do so.)
r) Timing annotation can also be described in terms of temporal decoupli ng. A non-zero ti mi ng
annotation can be considered as an i nvi tati on to the recipient to warp time. The recipient can
choose to enter a ti me warp, or it can put the transacti on i n a queue f or l ater processi ng and yi el d. I n
a loosely-ti med model, time warping is general ly acceptable. On the other hand, i f the target has
dependencies on other asynchronous events, the target may have to wai t f or simul ation ti me to
advance before it can predict the f uture state of the transaction wi th certainty.
s) For a general descri pti on of temporal decoupli ng, see 10.3.2.
t) For a description of the quantum, see 16.2.
Exampl e:
The f ol lowi ng pseudo-code f ragments i ll ustrate just some of the many possibl e codi ng styl es:
// ---------------------------------------------
// Vari ous interface method def initions
// ---------------------------------------------
void b_transport( TRANS& trans, sc_core::sc_time& t )
{
// Loosel y-timed codi ng style
execute_transaction( trans );
t = t + latency;
}
void b_transport( TRANS& trans, sc_core::sc_time& t )
{
// Loosely-timed wi th synchronization at the target or synchroni zati on-on-demand
wait( t );
execute_transaction( trans );
t = SC_ZERO_TIME;
}
tl m_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Pseudo-loosel y-ti med coding style using non-blocki ng transport (not recommended)
execute_transaction( trans );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


441
Copyright 2012 IEEE. All rights reserved.
t = t + latency;
return TLM_COMPLETED;
}
tl m_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Approximatel y-ti med coding style
// Post the transacti on i nto a payl oad event queue f or executi on at time sc_ti me_stamp() + t
payl oad_event_queue->noti fy( trans, phase, t );
// Increment the transaction ref erence count
trans.acquire();
return TLM_ACCEPTED;
}
tl m_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Approximatel y-timed coding style making use of the backward path
payl oad_event_queue->noti fy( trans, phase, t );
trans.acquire();
// Modif y the phase and ti me arguments
phase = END_REQ;
t = t + accept_delay;
return TLM_UPDATED;
}
// ---------------------------------------------------------------------------
// b_transport interface method call s, l oosely-timed codi ng style
// ---------------------------------------------------------------------------
ini ti al ize_transacti on( T1 );
socket->b_transport( T1, t ); // t may i ncrease
process_response( T1 );
ini ti al ize_transacti on( T2 );
socket->b_transport( T2, t ); // t may i ncrease
process_response( T2 );
// Ini tiator may sync after each transaction or after a seri es of transacti ons
quantum_keeper->set( t );
if ( quantum_keeper->need_sync() )
quantum_keeper->sync();
// -------------------------------------------------------------------------------------
// nb_transport interface method cal l, approxi mately-ti med coding styl e
// -------------------------------------------------------------------------------------
ini ti al ize_transacti on( T3 );
status = socket->nb_transport_fw( T3, phase, t );
if ( status == TLM_ACCEPTED )
{
// No acti on, but expect an incoming nb_transport_bw method cal l
}
else i f ( status == TLM_UPDATED ) // Backward path i s being used
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


442
Copyright 2012 IEEE. All rights reserved.
payl oad_event_queue->noti fy( T3, phase, t );
}
else i f ( status == TLM_COMPLETED ) // Early compl etion
{
// Timi ng annotati on may be taken i nto account in one of several ways
// Either (1) by waiting, as shown here
wait ( t );
process_response( T3 );
// or (2) by creati ng an event notif icati on
// response_event.noti fy( t );
// or (3) by being passed on to the next transport method call (code not shown here)
}
11.1.4 Migration path from TLM-1
The old TLM-1 and the new TLM-2.0 i nterf aces are both part of the TLM-2.0 standard. The TLM-1
blocking and non-blocki ng i nterf aces are sti ll useful in thei r own ri ght. For exampl e, a number of vendors
have used these interfaces in buildi ng f uncti onal veri fi cati on environments f or HDL designs.
The intent i s that the si mil ari ty between the old and new bl ocking transport i nterf aces should ease the task of
buildi ng adapters between legacy models using the TLM-1 i nterf aces and the new TLM-2.0 interfaces.
11.2 Direct memory interface
11.2.1 Introduction
The Direct Memory Interface, or DMI , provi des a means by which an initiator can get di rect access to an
area of memory owned by a target, thereafter accessing that memory using a di rect pointer rather than
through the transport i nterf ace. The DMI of fers a large potenti al i ncrease in simul ation speed for memory
access between ini ti ator and target because once establ ished i t is able to bypass the normal path of mul ti ple
b_tr anspor t or nb_transpor t cal ls from initiator through interconnect components to target.
There are two di rect memory interfaces, one f or call s on the f orward path f rom i ni ti ator to target, and a
second for cal ls on the backward path from target to ini ti ator. The f orward path is used to request a parti cul ar
mode of DMI access (e.g., read or write) to a gi ven address, and returns a reference to a DMI descriptor of
type tlm_dmi, whi ch contai ns the bounds of the DMI regi on. The backward path is used by the target to
invali date DMI poi nters previousl y establ ished using the forward path. The f orward and backward paths
may pass through zero, one, or many interconnect components, but i t shoul d be i dentical to the f orward and
backward paths f or the corresponding transport call s through the same sockets.
A DMI poi nter is requested by passing a transacti on along the f orward path. The def aul t DMI transaction
type i s tlm_gener ic_payload, where only the command and address attri butes of the transacti on obj ect are
used. DMI fol lows the same approach to extension as the transport interface; that is, a DMI request may con-
tai n i gnorabl e extensi ons, but any non-ignorabl e or mandatory extension requi res the defi niti on of a new
protocol traits class (see 14.2.2).
The DMI descri ptor returns l atency values f or use by the initiator and so provides suf fi cient ti ming accuracy
for loosel y-ti med modeli ng.
DMI pointers may be used f or debug, but the debug transport i nterf ace i tsel f is usuall y suff icient because
debug traff ic is usual ly l ight, and usuall y dominated by I /O rather than memory access. Debug transactions
are not usual ly on the critical path f or simul ation speed. If DMI poi nters were used f or debug, the l atency
val ues should be ignored.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


443
Copyright 2012 IEEE. All rights reserved.
11.2.2 Class definition
namespace tl m {
class tlm_dmi
{
publ ic:
tlm_dmi() { i ni t(); }

void init();
enum dmi _access_e {
DMI _ACCESS_NONE= 0x00,
DMI_ACCESS_READ = 0x01,
DMI_ACCESS_WRI TE= 0x02,
DMI_ACCESS_READ_WRI TE = DMI _ACCESS_READ | DMI _ACCESS_WRITE
} ;

unsi gned char* get_dmi_ptr () const;
sc_dt::uint64 get_start_addr ess() const;
sc_dt::uint64 get_end_address() const;
sc_core::sc_ti me get_read_latency() const;
sc_core::sc_ti me get_wr ite_latency() const;
dmi_access_e get_granted_access() const;
bool is_none_allowed() const;
bool is_read_allowed() const;
bool is_wr ite_allowed() const;
bool is_read_wr ite_allowed() const;
void set_dmi_ptr (unsigned char* p);
void set_start_address(sc_dt::uint64 addr);
void set_end_addr ess(sc_dt::uint64 addr);
void set_read_latency(sc_core::sc_time t);
void set_write_latency(sc_core::sc_time t);
void set_gr anted_access(dmi_access_e t);
void allow_none();
void allow_r ead();
void allow_write();
void allow_r ead_wr ite();
} ;
templ ate <typename TRANS = tl m_generi c_payl oad>
class tlm_fw_direct_mem_if : publi c vi rtual sc_core::sc_i nterf ace
{
publ ic:
virtual bool get_direct_mem_ptr(TRANS& trans, tl m_dmi& dmi _data) = 0;
} ;
class tlm_bw_dir ect_mem_if : publi c vi rtual sc_core::sc_interface
{
publ ic:
virtual void invalidate_direct_mem_ptr (sc_dt::ui nt64 start_range, sc_dt::uint64 end_range) = 0;
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


444
Copyright 2012 IEEE. All rights reserved.
} // namespace tl m
11.2.3 get_direct_mem_ptr method
a) The get_dir ect_mem_ptr method shall only be call ed by an initiator or by an interconnect
component, not by a target.
b) The transargument shall pass a ref erence to a DMI transacti on obj ect constructed by the initiator.
c) The dmi_data argument shall be a reference to a DMI descri ptor constructed by the ini tiator.
d) Any i nterconnect component should pass the get_dir ect_mem_ptr cal l al ong the forward path from
ini ti ator to target. In other words, the i mplementati on of get_direct_mem_ptr for the target socket
of the i nterconnect component may call the get_dir ect_mem_ptr method of an i ni ti ator socket.
e) Each get_dir ect_mem_ptr call shal l fol low exactly the same path from i niti ator to target as a
corresponding set of transport cal ls. In other words, each DMI request shall invol ve an interaction
between one ini ti ator and one target, where those two components al so serve the role of i nitiator and
target f or a single transacti on object passed through the transport i nterf ace. DMI cannot be used on a
path through a component that ini ti ates a second transaction object, such as a non-trivi al width
converter. (If DMI is an absolute requi rement f or si mulati on speed, the simulation model may need
to be restructured to permi t i t.)
f ) Any i nterconnect components shal l pass on the trans and dmi_data arguments in the forward
direction, the onl y permi tted modif icati on being to the value of the address attribute of the DMI
transaction object as described below. The address attri bute of the transaction and the DMI
descri ptor may both be modif ied on return f rom the get_dir ect_mem_ptr method, that i s, when
unwinding the function cal ls from target back to i niti ator.
g) I f the target i s abl e to support DMI access to the given address, it shall set the members of the DMI
descri ptor as descri bed below and set the return val ue of the f uncti on to true. When a target grants
DMI access, the DMI descriptor is used to indicate the detai ls of the access bei ng granted.
h) I f the target i s not abl e to support DMI access to the gi ven address, i t need set onl y the address range
and type members of the DMI descriptor as descri bed below and set the return value of the functi on
to false. When a target denies DMI access, the DMI descriptor i s used to i ndi cate the detail s of the
access bei ng denied.
i) A target may grant or deny DMI access to any part or parts of its memory region, including non-
contiguous regions, subject to the rul es given i n this cl ause.
j) I n the case that a target has granted DMI access and has set the return value of the f unction to true,
an i nterconnect component may deny DMI access by setti ng the return value of the functi on to false
on return f rom the get_dir ect_mem_ptr method. The reverse is not permi tted; i n the case that a
target has denied DMI access, an interconnect component shal l not grant DMI access.
k) Gi ven multipl e call s to get_direct_mem_ptr, a target may grant DMI access to multipl e i nitiators
f or the same memory regi on at the same ti me. The appl ication is responsibl e for synchronizati on and
coherency.
l) Since each cal l to get_dir ect_mem_ptr can onl y return a si ngl e DMI poi nter to a conti guous
memory region, each DMI request can only be fulf il led by a single target i n practi ce. I n other words,
if a memory region is scattered across mul ti pl e targets, then even though the address range is
contiguous, each target wi ll li kely require a separate DMI request.
m) I f read or write access to a certain region of memory causes side eff ects i n a target (that is, causes
some other change to the state of the target over and above the state of the memory), the target
should not grant DMI access of the gi ven type to that memory region. But if , f or example, only wri te
access causes side ef fects i n a target, the target may still grant DMI read access to a given region.
n) The i mplementati on of get_dir ect_mem_ptr may call invalidate_direct_mem_ptr.
o) The i mplementati on of get_dir ect_mem_ptr shall not cal l wait, directl y or indirectly.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


445
Copyright 2012 IEEE. All rights reserved.
11.2.4 template argument and tlm_generic_payload class
a) The tlm_fw_direct_mem_if template shal l be parameterized with the type of a DMI transacti on
class.
b) The transaction obj ect shal l contain attributes to indicate the address f or which direct memory
access is requested and the type of access requested, namely read access or write access to the given
address. In the case of the base protocol , these shal l be the command and address attributes of the
generic payload.
c) The default val ue of the TRANS template argument shal l be the class tlm_gener ic_payload.
d) For maximal i nteroperabili ty, the DMI transacti on class should be the tlm_gener ic_payload class.
The use of non-ignorabl e extensions or other transaction types wi ll restri ct interoperabil ity.
e) The i nitiator shall be responsibl e f or constructi ng and managing the DMI transaction object, and f or
setti ng the appropriate attributes of the object bef ore passing it as an argument to
get_dir ect_mem_ptr .
f ) The command attribute of the transacti on obj ect shal l be set by the initiator to indi cate the kind of
DMI access being requested, and shall not be modif ied by any interconnect component or target. For
the base protocol , the permi tted values are TLM_READ_COMMAND f or read access, and
TLM_WRITE_COMMAND f or write access.
g) For the base protocol , the command attri bute is forbi dden from having the val ue
TLM_I GNORE_COMMAND. However, this val ue may be used by other protocols.
h) The address attribute of the transacti on obj ect shal l be set by the initiator to indicate the address f or
which direct memory access is bei ng requested.
i ) An interconnect component passi ng the DMI transaction obj ect along the f orward path should
decode and where necessary modi fy the address attribute of the transacti on exactl y as it would for
the correspondi ng transport i nterf ace of the same socket. For example, an i nterconnect component
may need to mask the address (reduci ng the number of signif icant bits) according to the address
wi dth of the target and i ts location in the system memory map.
j ) An i nterconnect component need not pass on the get_direct_mem_ptr call in the event that i t
detects an addressing error.
k) I n the case of the base protocol, if the generic payl oad option attri bute i s TLM_MIN_PAYLOAD,
the initiator i s not obl iged to set any other attri butes of the generi c payl oad aside from command and
address, and the target and any interconnect components may i gnore all other attributes. I n
parti cul ar, the response status attribute and the DMI all owed attri bute may be ignored. I f the target
sets the value of the generi c payload opti on attri bute to TLM_FULL_PAYLOAD_ACCEPTED, the
target shal l set the response status attribute and the ini tiator shoul d check the response status as
descri bed in 14.8. The DMI all owed attribute is onl y i ntended for use with the transport and debug
transport interfaces.
l ) The initiator may re-use a transaction obj ect from one DMI call to the next and across cal ls to DMI,
the transport i nterf aces, and the debug transport i nterf ace.
m) I f an appli cation needs to add f urther attri butes to a DMI transaction obj ect for use by the target
when determining the kind of DMI access bei ng requested, the recommended approach i s to add
extensions to the generi c payl oad rather than substituting an unrelated transaction cl ass. For
exampl e, the DMI transaction might include a CPU ID to al low the target to service DMI requests
dif ferently dependi ng on the kind of CPU maki ng the request. I n the case that such extensions are
non-ignorable, thi s wi ll requi re the def inition of a new protocol traits class.
11.2.5 tlm_dmi class
a) A DMI descri ptor i s an obj ect of cl ass tlm_dmi. DMI descriptors shall be constructed by i nitiators,
but their members may be set by interconnect components or targets.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


446
Copyright 2012 IEEE. All rights reserved.
b) A DMI descri ptor shall have the f ol lowi ng attri butes: the DMI pointer attribute, the granted access
type attribute, the start address attribute, the end address attri bute, the read latency attri bute, and the
write l atency attribute. The def aul t val ues of these attributes shall be as f ol lows: DMI pointer
attri bute = 0, access type = DMI _ACCESS_NONE, start address = 0, end address = the maximum
val ue of type sc_dt::uint64, read l atency = SC_ZERO_TI ME, and wri te l atency =
SC_ZERO_TIME.
c) Method ini t shall ini tial ize the members of the DMI descri ptor to thei r default values.
d) A DMI descri ptor shall be in its default state whenever it is passed as an argument to
get_dir ect_mem_ptr by the i niti ator. I f DMI descri ptor objects are pooled, the i nitiator shall reset
the DMI descriptor to its def aul t state before passi ng it as an argument to get_dir ect_mem_ptr.
Method init may be cal led for this purpose.
e) Since an interconnect component i s not permitted to modif y the DMI descri ptor as i t i s passed on
toward the target, the DMI descri ptor shall be i n i ts initial state when i t i s received by the target.
f) The method set_dmi_ptr shall set the DMI pointer attri bute to the value passed as an argument. The
method get_dmi_ptr shall return the current val ue of the DMI pointer attribute.
g) The DMI poi nter attribute shall be set by the target to poi nt to the storage l ocation corresponding to
the val ue of the start address attribute. Thi s shal l be less than or equal to the address requested i n the
cal l to get_dir ect_mem_ptr. The i ni ti al val ue shal l be 0.
h) The storage in the DMI regi on is represented with type unsigned char * . The storage shall have the
same organizati on as the data array of the generic payload. I f a target is unable to return a poi nter to
a memory region with that organizati on, the target i s unabl e to support DMI and
get_dir ect_mem_ptr should return the val ue f al se. For a f ul l descri ption of how memory
organization and endi anness are handled i n TLM-2.0, see 14.18.
i ) An interconnect component i s permi tted to modif y the DMI poi nter attribute on the return path f rom
the get_dir ect_mem_ptr functi on cal l i n order to restrict the region to which DMI access i s being
granted.
j ) The method set_gr anted_access shal l set the granted access type attri bute to the val ue passed as an
argument. The method get_granted_accessshal l return the current val ue of the granted access type
attri bute. The i nitial value shall be DMI _ACCESS_NONE.
k) The methods allow_none, allow_r ead, allow_write, and allow_r ead_wr ite shal l set the granted
access type attri bute to the value DMI_ACCESS_NONE, DMI _ACCESS_READ,
DMI_ACCESS_WRI TE, or DMI _ACCESS_READ_WRI TE, respectively.
l ) The method is_none_allowed shall return true if and onl y i f the granted access type attribute has the
val ue DMI _ACCESS_NONE. The method is_read_allowed shal l return true i f and only if the
granted access type attribute has the val ue DMI _ACCESS_READ or
DMI_ACCESS_READ_WRI TE. The method is_wr ite_allowed shal l return true if and only i f the
granted access type attri bute has the value DMI_ACCESS_WRI TE or
DMI_ACCESS_READ_WRI TE. The method is_read_wr ite_allowed shal l return true if and onl y
if the granted access type attri bute has the val ue DMI_ACCESS_READ_WRITE.
m) The target shall set the granted access type attribute to the type of access bei ng granted or being
deni ed. A target is permitted to respond to a request for read access by granti ng (or denyi ng) read or
read/write access, and to a request for write access by granti ng (or denying) write or read/write
access. An interconnect component is permitted to restrict the granted access type by overwriting a
val ue of DMI _ACCESS_READ_WRI TE with DMI_ACCESS_READ or DMI_ACCESS_WRI TE
on the return path from the get_direct_mem_ptr function cal l.
n) A target wishing to deny read and write access to the DMI region should set the granted access type
to DMI_ACCESS_READ_WRI TE, not to DMI _ACCESS_NONE.
Exampl e:
bool get_di rect_mem_ptr( TRANS& trans, tlm::tlm_dmi & dmi_data )
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


447
Copyright 2012 IEEE. All rights reserved.
{
// Deny DMI access to enti r e memor y regi on
dmi _data.allow_read_wri te();
dmi _data.set_start_address( 0x0 );
dmi _data.set_end_address( (sc_dt::ui nt64)-1 );
return false;
}
o) The target should set the granted access type to DMI_ACCESS_NONE to i ndi cate that it i s not
granti ng (or denyi ng) read, write, or read/wri te access to the ini ti ator, but i t is granti ng (or denying)
some other ki nd of access as requested by an extensi on to the DMI transacti on object. This value
should only be used in cases where an extension to the DMI transacti on object makes the pre-
defi ned access types read, wri te, and read/write unnecessary or meaningl ess. This val ue should not
be used i n the case of the base protocol .
p) The i nitiator is responsible f or using only those modes of DMI access that have been granted by the
target (and possi bly modi fi ed by the i nterconnect) usi ng the granted access type attribute (or i n cases
other than the base protocol , granted using extensions to the generic payload or using other DMI
transaction types).
q) The methods set_star t_address and set_end_address shall set the start and end address attri butes,
respecti vel y, to the val ues passed as arguments. The methods get_start_addr ess and
get_end_address shall return the current val ues of the start and end address attributes, respectively.
r) The start and end address attri butes shall be set by the target (or modif ied by the interconnect) to
point to the addresses of the f irst and the l ast bytes i n the DMI region. The DMI regi on i s either
bei ng granted or being denied, as determi ned by the value returned from the get_dir ect_mem_ptr
method (true or false). A target wishing to deny access to i ts enti re memory region may set the start
address to 0 and the end address to the maxi mum val ue of type sc_dt::uint64.
s) A target can onl y grant or deny a si ngle conti guous memory regi on f or each get_dir ect_mem_ptr
cal l. A target can set the DMI region to a si ngle address by havi ng the start and end address
attri butes be equal or can set the DMI regi on to be arbitrari ly large.
t) Having been granted DMI access of a gi ven type to a gi ven regi on, an i niti ator may perform access
of the gi ven type anywhere in that region unti l it is i nvali dated. I n other words, access is not
restricted to the address gi ven in the DMI request.
u) Any i nterconnect components that pass on the get_dir ect_mem_ptr call are obliged to transf orm
the start and end address attributes as they do the address argument. Any transformations on the
addresses in the DMI descri ptor shall occur as the descriptor i s passed along the return path from the
get_dir ect_mem_ptr f uncti on call . For example, the target may set the start address attri bute to a
rel ative address within the memory map known to that target, in whi ch case the i nterconnect
component i s obli ged to transf orm the rel ative address back to an absolute address in the system
memory map. The i nitial val ues shall be 0 and the maxi mum val ue of type sc_dt::uint64,
respecti vel y.
v) An interconnect component is permi tted to modif y the start and end address attributes in order to
restrict the regi on to whi ch DMI access is being granted, or expand the range to which DMI access is
bei ng denied.
w) I f get_dir ect_mem_ptr returns the value true, the DMI region indicated by the start and end
address attri butes i s a regi on for which DMI access i s al lowed. On the other hand, if
get_dir ect_mem_ptr return the value false, i t is a regi on f or which DMI access is disal lowed.
x) A target or interconnect component receiving two or more call s to get_dir ect_mem_ptr may return
two or more overlapping all owed DMI regions or two or more overlappi ng disallowed DMI regi ons.
y) A target or interconnect component shal l not return overlappi ng DMI regi ons where one region is
all owed, and the other i s disal lowed f or the same access type, for exampl e, both read or read/write or
both wri te or read/wri te, wi thout making an i nterveni ng call to invalidate_direct_mem_ptr to
invali date the fi rst region.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


448
Copyright 2012 IEEE. All rights reserved.
z) I n other words, the defi nition of the DMI regions shall not be dependent on the order in whi ch they
were created unl ess the f irst region i s invali dated by an interveni ng call to
invalidate_direct_mem_ptr . Specif icall y, the creati on of a di sal lowed DMI regi on shal l not be
permi tted to punch a hole in an exi sting al lowed DMI regi on f or the same access type, or vice versa.
aa) A target may di sall ow DMI access to the entire address space (start address attribute = 0, end
address attri bute = maximum value), perhaps because the target does not support DMI access at all ,
in which case an interconnect component should cl ip thi s disal lowed regi on down to the part of the
memory map occupied by the target. Otherwise, if an i nterconnect component f ai ls to cli p the
address range, then an initiator would be misled into thinking that DMI was di sall owed across the
entire system address space.
ab) The methods set_read_latency and set_write_latency shall set the read and wri te l atency attributes,
respecti vel y, to the values passed as arguments. The methods get_read_latency and
get_wr ite_latency shal l return the current values of the read and wri te latency attributes,
respecti vel y.
ac) The read and wri te latency attri butes shal l be set to the average latency per byte f or read and wri te
memory transactions, respecti vel y. I n other words, the i ni ti ator performing the di rect memory
operation shal l calculate the actual latency by multi plying the read or write latency f rom the DMI
descri ptor by the number of bytes that woul d have been transf erred by the equivalent tr ansport
transaction. The i nitial val ues shal l be SC_ZERO_TIME. Both interconnect components and the
target may increase the val ue of either latency such that the latency accumulates as the DMI
descri ptor is passed back from target to i ni ti ator on return f rom the get_dir ect_mem_ptr method.
One or both l atenci es wil l be vali d, depending on the value of the granted access type attribute.
ad) The ini ti ator is responsi bl e f or respecting the latencies whenever it accesses memory usi ng the di rect
memory pointer. If the i ni ti ator chooses to i gnore the l atenci es, this may resul t in ti ming
inaccuraci es.
11.2.6 invalidate_direct_mem_ptr method
a) The invalidate_direct_mem_ptr method shall only be called by a target or an i nterconnect
component.
b) A target is obl iged to cal l invalidate_direct_mem_ptr bef ore any change that woul d modi fy the
validi ty or the access type of any exi sting DMI regi on. For example, bef ore restricti ng the address
range of an existing DMI regi on, bef ore changing the access type f rom read/wri te to read, or before
re-mappi ng the address space.
c) The star t_r ange and end_r ange arguments shall be the f irst and last addresses of the address range
f or which DMI access i s to be inval idated.
d) An initiator recei ving an i ncomi ng cal l to invalidate_direct_mem_ptr shall immedi atel y inval idate
and discard any DMI regi on (previousl y recei ved from a call to get_dir ect_mem_ptr) that overlaps
wi th the gi ven address range.
e) I n the case of a parti al overl ap, that i s, onl y part of an existi ng DMI region is i nvali dated, an ini ti ator
may adj ust the boundari es of the exi sting region or may inval idate the entire regi on.
f ) Each DMI regi on shal l remain valid unti l i t i s expli citly invalidated by a target using a call to
invalidate_direct_mem_ptr . Each initiator may maintai n a table of val id DMI regions and may
continue to use each regi on until it is inval idated.
g) Any interconnect components are obl iged to pass on the invalidate_direct_mem_ptr cal l along the
backward path f rom target to ini ti ator, decoding and where necessary modi fying the address
arguments as they would f or the corresponding transport interface. Because the transport interface
transf orms the address on the f orward path and DMI on the backward path, the transport and DMI
transf ormati ons should be the i nverse of one another.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


449
Copyright 2012 IEEE. All rights reserved.
h) Gi ven a single invalidate_direct_mem_ptr call f rom a target, an i nterconnect component may
make mul ti pl e invalidate_direct_mem_ptr cal ls to i nitiators. Since there may be multiple ini tiators
each getting direct memory pointers to the same target, a safe i mplementation is f or an interconnect
component to cal l invalidate_direct_mem_ptr for every ini tiator.
i ) An interconnect component can i nval idate all di rect memory pointers i n an ini ti ator by setti ng
star t_r ange to 0 and end_r ange to the maximum value of the type sc_dt::uint64.
j) The i mplementati on of any TLM-2.0 core interface method may call invalidate_direct_mem_ptr.
k) The i mplementati on of invalidate_direct_mem_ptr shall not cal l get_dir ect_mem_ptr, directl y or
indi rectly.
l) The i mplementati on of invalidate_direct_mem_ptr shall not cal l wait, di rectl y or indirectly.
11.2.7 DMI versus transport
a) By def inition, the di rect memory i nterf ace provi des a direct interface between ini ti ator and target
that bypasses any i nterconnect components. The transport interfaces, on the other hand, cannot
bypass i nterconnect components.
b) Care must be taken to ensure correct behavi or when an interconnect component retai ns state or has
side ef fects, such as buf fered i nterconnects or i nterconnects model ing cache memory. The transport
interfaces may access and update the state of the interconnect component, whereas the di rect
memory interface wil l bypass the i nterconnect component. The saf est al ternati ve is f or such
interconnect components al ways to deny DMI access.
c) I t is possi bl e f or an initiator to switch back and f orth between call ing the transport i nterf aces and
usi ng a direct memory pointer. It i s al so possibl e that one i ni ti ator may use DMI, whi le another
ini ti ator i s using the transport i nterf aces. Care must be taken to ensure correct behavior, particularly
consideri ng that transport call s may carry a ti mi ng annotation. This i s the responsibil ity of the
appl icati on. For example, a given target coul d support DMI and transport simul taneously or could
invali date every DMI poi nter whenever transport is call ed.
11.2.8 DMI and temporal decoupling
a) A DMI regi on can only be inval idated by means of a target or i nterconnect component maki ng a call
to invalidate_direct_mem_ptr .
b) An i ni ti ator i s responsi ble for checki ng that a DMI region i s sti ll val id bef ore usi ng the associated
DMI pointer, subj ect to the fol lowing considerati ons.
c) The co-routine semanti cs of SystemC guarantee that once an i ni ti ator has started running, no other
SystemC process will be able to run unti l the ini ti ator yi elds. In particular, no other SystemC process
would be abl e to invali date a DMI poi nter (al though the current process mi ght). As a consequence, a
temporal ly decoupled i ni ti ator does not necessaril y need to check repeatedly that a given DMI
region is stil l vali d each time it uses the associated DMI poi nter.
d) It is possi ble that an interface method cal l made from an ini ti ator may cause another component to
cal l invalidate_direct_mem_ptr , thus i nvali dating a DMI region bei ng used by that i ni ti ator. This
coul d be true of a temporal ly decoupl ed i niti ator that runs wi thout yieldi ng.
e) Whi le an i ni ti ator is running wi thout interacti ng with any other components and without yieldi ng,
any vali d DMI regi on wi ll remain val id.
f ) It is possi ble that af ter a temporall y decoupled initiator usi ng DMI has yi el ded, another temporal l y
decoupled i ni ti ator may cause that same DMI regi on to be i nvali dated within the current time
quantum. This ref l ects the f undamental inaccuracy intri nsi c to temporal decoupl ing i n general but
does not represent a violation of the rul es given i n this cl ause.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


450
Copyright 2012 IEEE. All rights reserved.
11.2.9 Optimization using a DMI hint
a) The DMI hi nt, otherwi se known as the DMI al lowed attri bute, is a mechani sm to opti mi ze
simul ation speed by avoiding the need to pol l repeatedl y f or DMI access. Instead of call ing
get_dir ect_mem_ptr to check for the avai labili ty of a DMI pointer, an initiator can check the DMI
all owed attribute of a normal transaction passed through the transport interface.
b) The generic payload provides a DMI all owed attribute. User-def ined transactions coul d i mplement a
simi lar mechanism, i n which case the target should set the val ue of the DMI al lowed attribute
appropriatel y.
c) Use of the DMI allowed attribute is optional. An ini ti ator is free to ignore the DMI all owed attri bute
of the generic payload.
d) For an initiator wishing to take advantage of the DMI all owed attri bute, the recommended sequence
of acti ons is as fol lows:
1) The initiator should check the address against its cache of val id DMI regions.
2) I f there is no existi ng DMI poi nter, the i ni ti ator should perf orm a normal transaction through
the transport i nterf ace.
3) Foll owing that, the ini ti ator should check the DMI al lowed attri bute of the transacti on.
4) I f the attri bute indi cates DMI i s al lowed, the i ni ti ator should call get_dir ect_mem_ptr.
5) The initiator should modif y its cache of val id DMI regions according to the values returned
f rom the cal l.
11.3 Debug transport interface
11.3.1 Introduction
The debug transport interface provides a means to read and wri te to storage in a target, over the same
f orward path from i nitiator to target as is used by the transport interface, but wi thout any of the delays, waits,
event notif icati ons, or si de ef fects associ ated wi th a regul ar transaction. I n other words, the debug transport
interface is non-intrusi ve. Because the debug transport interface f oll ows the same path as the transport
interface, the impl ementation of the debug transport interface can perf orm the same address transl ation as
for regular transactions.
For exampl e, the debug transport interface could permit a software debugger attached to an I SS to peek or
poke an address in the memory of the simul ated system from the point of vi ew of the simul ated CPU. The
debug transport interf ace coul d al so allow an i nitiator to take a snapshot of system memory contents during
simul ation for di agnostic purposes, or to i nitiali ze some area of system memory at the end of elaborati on.
The default debug transacti on type i s tlm_gener ic_payload, where only the command, address, data l ength,
and data pointer attributes of the transaction obj ect are used. Debug transactions f ol low the same approach
to extensi on as the transport i nterface; that i s, a debug transacti on may contai n i gnorabl e extensi ons, but any
non-ignorable or mandatory extension requires the def inition of a new protocol traits cl ass (see 7.2.2).
11.3.2 Class definition
namespace tl m {
templ ate <typename TRANS = tl m_generi c_payl oad>
class tlm_transpor t_dbg_if : publi c virtual sc_core::sc_interface
{
publ ic:
vi rtual unsigned i nt tr anspor t_dbg(TRANS& trans) = 0;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


451
Copyright 2012 IEEE. All rights reserved.
} ;
} // namespace tl m
11.3.3 TRANS template argument and tlm_generic_payload class
a) The tlm_transpor t_dbg_if templ ate shal l be parameterized with the type of a debug transacti on
class.
b) The debug transacti on class shal l contai n attributes to indicate to the target the command, address,
data l ength, and date poi nter f or the debug access. I n the case of the base protocol , these shall be the
correspondi ng attri butes of the generi c payload.
c) The default val ue of the TRANS template argument shal l be the class tlm_gener ic_payload.
d) For maxi mal interoperabil ity, the debug transacti on cl ass should be tlm_gener ic_payload. The use
of non-i gnorable extensi ons or other transaction types wi ll restri ct interoperabil ity.
e) I f an appli cation needs to add f urther attributes to a debug transaction, the recommended approach is
to add extensions to the generi c payl oad rather than substi tuti ng an unrelated transacti on class. I n the
case that such extensi ons are non-ignorable or mandatory, this wil l requi re the defi ni ti on of a new
protocol traits cl ass.
11.3.4 Rules
a) Call s to transpor t_dbg shal l fol low the same forward path asthe transport interface used for normal
transactions.
b) The transargument shall pass a ref erence to a debug transacti on object.
c) The initiator shal l be responsi bl e for constructi ng and managi ng the debug transacti on obj ect, and
f or setting the appropriate attributes of the object bef ore passi ng it as an argument to
transpor t_dbg.
d) The command attribute of the transacti on obj ect shal l be set by the initiator to indi cate the kind of
debug access being requested, and shal l not be modi f ied by any interconnect component or target.
For the base protocol, the permi tted val ues are TLM_READ_COMMAND f or read access to the
target, TLM_WRITE_COMMAND f or write access to the target, and
TLM_I GNORE_COMMAND.
e) On recei pt of a transacti on wi th the command attribute equal to TLM_I GNORE_COMMAND, the
target should not execute a read or a wri te, but may use the val ue of any attribute in the generi c
payl oad, including any extensi ons, in executing an extended debug transacti on.
f ) As is the case for the transport interface, the use of any non-i gnorable or mandatory generic payl oad
extension wi th the debug transport interface requi res the def ini tion of a new protocol traits cl ass.
g) The address attribute shall be set by the initiator to the fi rst address i n the region to be read or
written.
h) An interconnect component passing the debug transacti on obj ect al ong the forward path should
decode and where necessary modi fy the address attribute of the transaction obj ect exactl y as i t
would for the correspondi ng transport interface of the same socket. For example, an i nterconnect
component may need to mask the address (reduci ng the number of signif icant bits) accordi ng to the
address width of the target and i ts location in the system memory map.
i) An interconnect component need not pass on the transpor t_dbg cal l in the event that i t detects an
addressing error.
j ) The address attri bute may be modi fi ed several ti mes i f a debug payload i s forwarded through several
interconnect components. When the debug payload i s returned to the i ni ti ator, the original val ue of
the address attribute may have been overwritten.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


452
Copyright 2012 IEEE. All rights reserved.
k) The data l ength attri bute shal l be set by the i ni ti ator to the number of bytes to be read or wri tten and
shal l not be modif ied by any interconnect component or target. The data l ength attribute may be 0, in
which case the target shal l not read or write any bytes, and the data pointer attri bute may be nul l.
l ) The data pointer attri bute shall be set by the ini tiator to the address of an array from whi ch val ues are
to be copi ed to the target (for a wri te), or to which values are to be copi ed from the target (for a
read), and shall not be modi fi ed by any i nterconnect component or target. This array shall be
all ocated by the i nitiator and shal l not be del eted bef ore the return f rom transpor t_dbg. The si ze of
the array shal l be at l east equal to the val ue of the data l ength attri bute. If the data l ength attri bute is
0, the data pointer attribute may be the nul l pointer and the array need not be al located.
m) The impl ementation of transpor t_dbg i n the target shall read or write the given number of bytes
usi ng the given address (after address translation through the i nterconnect), i f it i s able. I n the case
of a wri te command, the target shal l not modif y the contents of the data array.
n) The data array shall have the same organi zation as the data array of the generi c payl oad when used
wi th the transport i nterf ace. The impl ementation of transpor t_dbg shal l be responsibl e for
converting between the organi zation of the local data storage wi thin the target and the generi c
payl oad organization.
o) I n the case of the base protocol, if the generic payl oad option attri bute i s TLM_MIN_PAYLOAD,
the i nitiator is not obl iged to set any other attributes of the generic payload asi de f rom command,
address, data l ength and data pointer, and the target and any interconnect components may ignore al l
other attri butes. In parti cul ar, the response status attribute may be ignored.
p) I n the case of the base protocol, if the initiator sets the val ue of the generic payl oad option attribute
to TLM_FULL_PAYLOAD, the initiator shall set the values of the byte enable pointer, byte enabl e
length, and streami ng wi dth attributes, and shal l set the DMI al l owed and response status attributes
to thei r def aul t values as described i n 14.8.
q) I n the case of the base protocol , i f the target sets the val ue of the generi c payload option attri bute to
TLM_FULL_PAYLOAD_ACCEPTED, the target shall act on the values of the byte enabl e pointer,
byte enable length, and streaming wi dth attributes, and shall set the DMI al l owed and response
status attributes as described in 14.8.
r) The ini ti ator may re-use a transaction object from one call to the next and across call s to the debug
transport interface, the transport interf aces, and DMI .
s) transpor t_dbg shal l return a count of the number of bytes actually read or written, which may be
less than the val ue of the data length attri bute. I n the case of the base protocol , i f the initiator sets the
val ue of the generi c payl oad option attribute to TLM_FULL_PAYLOAD, the count shal l include
both enabl ed and di sabl ed bytes. If the target is not able to perform the operation, it shal l return a
val ue of 0. I n the case of TLM_IGNORE_COMMAND, the target is free to choose the val ue
returned f rom transpor t_dbg.
t) Di rectl y or i ndi rectl y, transpor t_dbg shall not cal l wait, and should not cause any state changes i n
any i nterconnect component or i n the target asi de f rom the immedi ate ef fect of executing a debug
write command.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


453
Copyright 2012 IEEE. All rights reserved.
12. TLM-2.0 global quantum
12.1 Introduction
Temporal decoupli ng permits SystemC processes to run ahead of si mulation ti me for an amount of ti me
known as the ti me quantum and is associ ated with the l oosely-timed codi ng style. Temporal decoupli ng per-
mi ts a si gni fi cant simul ation speed improvement by reduci ng the number of context swi tches and events.
The use of a time quantum is not strictl y necessary i n the presence of expli ci t synchroni zati on between tem-
porall y decoupled processes, i n which case processes may run arbi traril y f ar ahead to the point when the
next synchronizati on point is reached. However, any processes that do require a ti me quantum should use
the global quantum.
When usi ng temporal decoupl ing, the del ays annotated to the b_tr anspor t and nb_transpor t methods are to
be interpreted as local time of fsets defi ned relati ve to the current simulati on ti me as returned by
sc_time_stamp(), also known as the quantum boundary. The global quantum i s the def aul t ti me interval
between successi ve quantum boundari es. The value of the gl obal ti me quantum is mai ntained by the
singleton cl ass tlm_global_quantum. I t is recommended that each process should use the global time
quantum, but a process i s permitted to calculate its own local ti me quantum.
For a general descripti on of temporal decoupli ng, see 10.3.2.
For a description of ti mi ng annotation, see 11.1.3.
The util ity class tlm_quantumkeeper provides a set of methods f or managi ng and interacti ng wi th the ti me
quantum. For a descri ption of how to use a quantum keeper, see 16.2.
12.2 Header file
The class defi ni ti on f or the global quantum shal l be in the header fi le tlm.
12.3 Class definition
namespace tl m {
class tlm_global_quantum
{
publ ic:
stati c tlm_global_quantum& instance();
virtual ~tlm_global_quantum();
void set( const sc_core::sc_time& );
const sc_core::sc_ti me& get() const;
sc_core::sc_ti me compute_local_quantum();
protected:
tlm_global_quantum();
} ;
} // namespace tl m
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


454
Copyright 2012 IEEE. All rights reserved.
12.4 Class tlm_global_quantum
a) There is a uni que global quantum maintai ned by the cl ass tlm_global_quantum. This should be
considered the default time quantum. The intent i s that all temporall y decoupled i nitiators should
synchronize on i nteger mul ti ples of the gl obal quantum, or more frequently where requi red.
b) I t i s possible f or each ini ti ator to use a diff erent ti me quantum but more typical for al l i niti ators to
use the global quantum. An i ni ti ator that onl y requires infrequent synchroni zation could concei vably
have a l onger ti me quantum than the rest, but i t i s usuall y the shortest time quantum that has the
biggest negative impact on si mul ati on speed.
c) The method instance shall return a ref erence to the si ngl eton gl obal quantum obj ect.
d) The method set shal l set the value of the global quantum to the value passed as an argument.
e) The method get shall return the value of the global quantum.
f) The method compute_local_quantum shall calculate and return the value of the l ocal quantum
based on the unique gl obal quantum. The local quantum shal l be cal cul ated by subtracting the val ue
of sc_time_stamp f rom the next larger integer mul ti pl e of the gl obal quantum. The l ocal quantum
shal l equal the gl obal quantum in the case where compute_local_quantum is cal led at a si mulati on
ti me that i s an i nteger mul ti pl e of the gl obal quantum. Otherwise, the l ocal quantum shal l be less
than the gl obal quantum.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


455
Copyright 2012 IEEE. All rights reserved.
13. Combined TLM-2.0 interfaces and sockets
13.1 Combined interfaces
13.1.1 Introduction
The combined forward and backward transport i nterf aces group the core TLM-2.0 interfaces for use by the
ini ti ator and target sockets. Note that the combined interfaces include the transport, DMI , and debug
transport i nterf aces, but they do not include any TLM-1 core i nterf aces. The f orward interf ace provi des
method cal ls on the f orward path f rom i nitiator socket to target socket, and the backward i nterf ace on the
backward path f rom target socket to ini ti ator socket. Neither the blocking transport interface nor the debug
transport interf ace require a backward call ing path.
I t woul d be techni cal ly possi ble to def ine new socket class templates unrelated to the standard initiator and
target sockets and then to instantiate those cl ass templ ates using the combined i nterf aces as templ ate
arguments, but for the sake of interoperabi lity, thi s i s not recommended. On the other hand, deri vi ng new
socket classes f rom the standard sockets is recommended f or conveni ence.
The combi ned interface templates are parameteri zed with a protocol tr ai ts cl ass that defi nes the types used
by the f orward and backward interfaces, namel y, the payload type and the phase type. A protocol traits class
is associ ated wi th a speci f ic protocol . The def ault protocol type i s the cl ass tlm_base_protocol_types (see
15.2).
13.1.2 Class definition
namespace tl m {
// The default protocol trai ts class:
struct tlm_base_protocol_types
{
typedef tlm_generi c_payl oad tl m_payload_type;
typedef tlm_phase tl m_phase_type;
} ;
// The combined f orward i nterf ace:
templ ate< typename TYPES = tl m_base_protocol _types >
class tlm_fw_tr ansport_if
: publi c virtual tlm_f w_nonblocking_transport_if <typename TYPES::tlm_payload_type ,
typename TYPES::tl m_phase_type>
, publ ic virtual tl m_blocki ng_transport_if < typename TYPES::tl m_payl oad_type>
, publ ic virtual tl m_fw_direct_mem_i f < typename TYPES::tl m_payload_type>
, publ ic virtual tl m_transport_dbg_i f< typename TYPES::tl m_payload_type>
{ } ;
// The combined backward i nterf ace:
templ ate < typename TYPES = tl m_base_protocol _types >
class tlm_bw_transport_i f
: publi c virtual tlm_bw_nonbl ocking_transport_i f< typename TYPES::tl m_payload_type ,
typename TYPES::tl m_phase_type >
, publ ic virtual tl m_bw_di rect_mem_if
{ } ;
} // namespace tl m
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


456
Copyright 2012 IEEE. All rights reserved.
13.2 Initiator and target sockets
13.2.1 Introduction
A socket combines a port wi th an export. An i nitiator socket has a port f or the forward path and an export for
the backward path, whil e a target socket has an export for the forward path and a port for the backward path.
The sockets also overload the SystemC port bi ndi ng operators to bind both the port and export to the export
and port in the opposi ng socket. When bindi ng sockets hierarchi call y, parent to chil d or chi ld to parent, it is
important to careful ly consider the binding order.
Both the initiator and target sockets are coded using a C++ i nheritance hi erarchy. Only the most derived
classes tlm_initiator _socket and tlm_tar get_socket are typi call y used directl y by appl ications. These two
sockets are parameterized with a protocol trai ts class that defi nes the types used by the f orward and
backward interfaces. Sockets can only bebound together if they have the identi cal protocol type. The def aul t
protocol type is the cl ass tlm_base_protocol_types. If an appl icati on defi nes a new protocol , it shoul d
instanti ate combi ned i nterf ace templ ates wi th a new protocol traits cl ass, whether or not the new protocol is
based on the generi c payload.
The i niti ator and target sockets provi de the f ol lowi ng benef its:
a) They group the transport, direct memory, and debug transport interfaces f or both the f orward and
backward paths together i nto a single object.
b) They provi de methods to bind port and export of both the f orward and backward paths i n a single
cal l.
c) They of fer strong type checki ng when binding sockets parameteri zed wi th i ncompati bl e protocol
types.
d) They i ncl ude a bus width parameter that may be used to interpret the transaction.
The socket cl asses tlm_initiator _socket and tlm_target_socket bel ong to the interoperabil ity l ayer of the
TLM-2.0 standard. In addition, there i s a f amil y of derived socket classes provided i n the util ities
namespace, col lectively known as conveni ence sockets.
13.2.2 Class definition
namespace tl m {
// Abstract base class f or initiator sockets
templ ate <
unsi gned int BUSWIDTH = 32,
typename FW_I F = tlm_f w_transport_i f<>,
typename BW_I F = tl m_bw_transport_if <>
>
class tlm_base_initiator _socket_b
{
publ ic:
virtual ~tlm_base_initiator _socket_b() { }
virtual sc_core::sc_port_b<FW_I F> & get_base_por t() = 0;
virtual const sc_core::sc_port_b<FW_IF> & get_base_por t() const = 0;
virtual BW_I F & get_base_inter face() = 0;
virtual const BW_IF & get_base_inter face() const = 0;
virtual sc_core::sc_export<BW_I F> & get_base_export() = 0;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


457
Copyright 2012 IEEE. All rights reserved.
virtual const sc_core::sc_export<BW_IF> & get_base_export() const = 0;
} ;
// Abstract base class for target sockets
templ ate <
unsi gned int BUSWIDTH = 32,
typename FW_I F = tlm_f w_transport_i f<>,
typename BW_I F = tl m_bw_transport_if <>
>
class tlm_base_tar get_socket_b
{
publ ic:
virtual ~tlm_base_tar get_socket_b();
virtual sc_core::sc_port_b<BW_I F> & get_base_por t() = 0;
virtual const sc_core::sc_port_b<BW_IF> & get_base_por t() const = 0;
virtual sc_core::sc_export<FW_I F> & get_base_export() = 0;
virtual const sc_core::sc_export <FW_I F> & get_base_export() const = 0;
virtual FW_IF & get_base_inter face() = 0;
virtual const FW_I F & get_base_inter face() const = 0;
} ;
// Base cl ass for i nitiator sockets, providing binding methods
templ ate <
unsi gned int BUSWIDTH = 32,
typename FW_I F = tlm_f w_transport_i f<>,
typename BW_I F = tl m_bw_transport_if <>,
int N = 1,
sc_core::sc_port_pol icy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class tlm_base_initiator _socket : publi c tlm_base_ini tiator_socket_b<BUSWI DTH, FW_I F, BW_IF>,
publ ic sc_core::sc_port<FW_IF, N, POL>
{
publ ic:
typedef FW_IF f w_i nterf ace_type;
typedef BW_I F bw_interface_type;
typedef sc_core::sc_port<f w_i nterface_type, N, POL> port_type;
typedef sc_core::sc_export<bw_interface_type> export_type;
typedef tl m_base_target_socket_b<BUSWI DTH, fw_interface_type, bw_interface_type>
base_initiator_socket_type;
typedef tl m_base_i ni ti ator_socket_b<BUSWIDTH, f w_interf ace_type, bw_i nterf ace_type>
base_type;
tlm_base_initiator _socket();
expl icit tlm_base_initiator_socket(const char* name);
virtual const char* kind() const;
unsi gned int get_bus_width() const;
virtual void bind(base_target_socket_type& s);
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


458
Copyright 2012 IEEE. All rights reserved.
void oper ator () (base_target_socket_type& s);
virtual void bind(base_type& s);
void oper ator () (base_type& s);
virtual void bind(bw_i nterf ace_type& if s);
void oper ator () (bw_i nterf ace_type& s);
// Impl ementation of pure virtual functions of base cl ass
virtual sc_core::sc_port_b<FW_I F> & get_base_por t() { return * thi s; }
virtual const sc_core::sc_port_b<FW_IF> & get_base_por t() const { return * this; }
virtual BW_I F & get_base_inter face() { return m_export; }
virtual const BW_IF & get_base_inter face() const { return m_export; }
virtual sc_core::sc_export<BW_I F> & get_base_export() { return m_export; }
virtual const sc_core::sc_export<BW_IF> & get_base_export() const { return m_export; }
protected:
export_type m_export;
} ;
// Base cl ass for target sockets, provi di ng bi ndi ng methods
templ ate <
unsi gned int BUSWIDTH = 32,
typename FW_I F = tlm_f w_transport_i f<>,
typename BW_I F = tl m_bw_transport_if <>,
int N = 1,
sc_core::sc_port_poli cy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class tlm_base_tar get_socket : public tl m_base_target_socket_b<BUSWI DTH, FW_IF, BW_IF>,
publ ic sc_core::sc_export<FW_I F>
{
publ ic:
typedef FW_IF fw_i nterf ace_type;
typedef BW_IF bw_interf ace_type;
typedef sc_core::sc_port<bw_interface_type, N, POL> port_type;
typedef sc_core::sc_export<fw_interface_type> export_type;
typedef tl m_base_i ni ti ator_socket_b<BUSWIDTH, f w_interf ace_type, bw_i nterf ace_type>
base_initiator_socket_type;
typedef tl m_base_target_socket_b<BUSWI DTH, fw_interface_type, bw_interface_type>
base_type;
tlm_base_tar get_socket();
expl icit tlm_base_tar get_socket(const char* name);
virtual const char* kind() const;
unsi gned int get_bus_width() const;
virtual void bind(base_ini ti ator_socket_type& s);
void oper ator () (base_i ni ti ator_socket_type& s);
virtual void bind(base_type& s);
void oper ator () (base_type& s);
virtual void bind(fw_interface_type& i fs);
void oper ator () (fw_i nterface_type& s);
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


459
Copyright 2012 IEEE. All rights reserved.
int size() const;
bw_interface_type* oper ator-> ();
bw_interface_type* oper ator [] (i nt i );
// Impl ementation of pure virtual functions of base cl ass
virtual sc_core::sc_port_b<BW_I F> & get_base_por t() { return m_port; }
virtual const sc_core::sc_port_b<BW_IF> & get_base_por t() const { return * this; }
virtual FW_IF & get_base_inter face() { return * thi s; }
virtual const FW_I F & get_base_inter face() const { return * this; }
virtual sc_core::sc_export<FW_I F> & get_base_export() { return * thi s; }
virtual const sc_core::sc_export<FW_I F> & get_base_export() const { return * thi s; }
protected:
port_type m_port;
} ;
// Pri nci pal i nitiator socket, parameterized wi th protocol traits class
templ ate <
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm_base_protocol_types,
int N = 1,
sc_core::sc_port_poli cy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class tlm_initiator _socket : publi c tlm_base_initiator_socket <
BUSWIDTH, tlm_f w_transport_if <TYPES>, tl m_bw_transport_if <TYPES>, N, POL>
{
publ ic:
tlm_initiator _socket();
expl icit tlm_initiator _socket(const char* name);
virtual const char* kind() const;
} ;
// Pri nci pal target socket, parameterized wi th protocol traits class
templ ate <
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm_base_protocol_types,
int N = 1,
sc_core::sc_port_poli cy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class tlm_tar get_socket : publi c tlm_base_target_socket <
BUSWIDTH, tlm_f w_transport_if <TYPES>, tl m_bw_transport_if <TYPES>, N, POL>
{
publ ic:
tlm_tar get_socket();
expl icit tlm_tar get_socket(const char* name);
virtual const char* kind() const;
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


460
Copyright 2012 IEEE. All rights reserved.
} // namespace tl m
13.2.3 Classes tlm_base_initiator_socket_b and tlm_base_target_socket_b
a) The abstract base classes tlm_base_initiator _socket_b and tlm_base_tar get_socket_b decl are
pure vi rtual f uncti ons that shoul d be overri dden in any derived class to return the port, export, and
interface obj ects associ ated wi th the socket.
b) These sockets are not typi call y used directl y by appl ications.
13.2.4 Classes tlm_base_initiator_socket and tlm_base_target_socket
a) For class tlm_base_initiator_socket, the constructor wi th a name argument shall pass the character
string argument to the constructor belonging to the base cl ass sc_por t to set the stri ng name of the
instance i n the module hierarchy, and shall also pass the same character stri ng to set the string name
of the correspondi ng sc_expor t on the backward path, adding the suf fi x " _expor t" and cal li ng
sc_gen_unique_name to avoi d name clashes. For example, the cal l tlm_initiator _socket(" foo" )
would set the port name to " foo" and the export name to " foo_expor t" . In the case of the def aul t
constructor, the names shall be created by calli ng
sc_gen_unique_name(" tlm_base_initiator_socket" ) for the port, and
sc_gen_unique_name(" tlm_base_initiator _socket_expor t" ) for the export.
b) For cl ass tlm_base_tar get_socket, the constructor with a name argument shall pass the character
string argument to the constructor belongi ng to the base class sc_expor t to set the stri ng name of the
instance i n the module hierarchy, and shall also pass the same character stri ng to set the string name
of the corresponding sc_por t on the backward path, addi ng the suf fi x " _por t" and cal li ng
sc_gen_unique_name to avoid name cl ashes. For exampl e, the call tlm_tar get_socket("foo")
would set the export name to " foo" and the port name to " foo_por t" . In the case of the def aul t con-
structor, the names shall be created by calli ng sc_gen_unique_name(" tlm_base_tar get_socket" )
f or the export, and sc_gen_unique_name(" tlm_base_tar get_socket_por t" ) for the port.
c) The method kind shall return the class name as a C stri ng, that is, "tlm_base_initiator_socket" or
"tl m_base_target_socket", respecti vel y.
d) The method get_bus_width shall return the value of the BUSWIDTH template argument.
e) Template argument BUSWI DTH shall determine the word l ength f or each i ndi vidual data word
transf erred through the socket, expressed as the number of bi ts in each word. For a burst transf er,
BUSWIDTH shall determi ne the number of bits in each beat of the burst. The precise interpretati on
of thi s attri bute shall depend on the transaction type. For the meaning of BUSWIDTH with the
generic payload, see 14.12.
f ) When bi ndi ng socket-to-socket, the two sockets shall have identical val ues for the BUSWI DTH
templ ate argument. Executabl e code i n the i ni ti ator or target may get and act on the BUSWI DTH.
g) Each of the methods bind and oper ator () that take a socket as an argument shall bind the socket
instance to whi ch the method bel ongs to the socket i nstance passed as an argument to the method.
h) Each of the methods bind and oper ator () that take an interface as an argument shall bi nd the export
of the socket instance to which the method belongs to the channel instance passed as an argument to
the method. (A channel is the SystemC term f or a class that i mpl ements an interface.)
i) I n each case, the i mplementati on of oper ator () shall achi eve i ts eff ect by calli ng the correspondi ng
virtual method bind.
j) When binding i niti ator socket to target socket, the bind method and operator() shal l each bind the
port of the ini tiator socket to the export of the target socket, and the port of the target socket to the
export of the ini ti ator socket. This i s for use when bi ndi ng socket-to-socket at the same level i n the
hierarchy.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


461
Copyright 2012 IEEE. All rights reserved.
k) An ini ti ator socket can be bound to a target socket by call ing the bi nd method or operator() of ei ther
socket, with preci sel y the same eff ect. I n either case, the forward path l ies in the direction f rom the
ini ti ator socket to the target socket.
l ) When binding i nitiator socket to initiator socket or target socket to target socket, the bind method
and operator() shal l each bi nd the port of one socket to the port of the other socket, and the export of
one socket to the export of the other socket. Thi s i s f or use in hierarchi cal bi ndi ng, that i s, when
binding a socket on a chi ld module to a socket on a parent modul e, or a socket on a parent modul e to
a socket on a chi ld modul e, passing transactions up or down the modul e hierarchy.
m) For hierarchical binding, it is necessary to bi nd sockets i n the correct order. When bi ndi ng i ni ti ator
socket to ini tiator socket, the socket of the chi ld must be bound to the socket of the parent. When
binding target socket to target socket, the socket of the parent must be bound to the socket of the
chi ld. This rul e is consistent wi th the f act the tlm_base_initiator _socket i s deri ved f rom sc_por t,
and tlm_base_tar get_socket f rom sc_expor t. Port must be bound to port goi ng up the hierarchy,
port-to-export across the top, and export-to-export going down the hierarchy.
n) I n order for two sockets of cl asses tlm_base_initiator_socket and tlm_base_tar get_socket to be
bound together, they must share the same forward and backward interface types and bus wi dths.
o) The method size of the target socket shal l call method size of the port in the target socket (on the
backward path), and shal l return the value returned by size of the port.
p) The method oper ator-> of the target socket shall cal l method oper ator-> of the port in the target
socket (on the backward path), and shal l return the value returned by oper ator-> of the port.
q) The method oper ator [] of the target socket shal l cal l method oper ator [] of the port in the target
socket (on the backward path) wi th the same argument, and shall return the val ue returned by
oper ator [] of the port.
r) Cl ass tlm_base_initiator _socket and class tlm_base_tar get_socket each act as mul ti -sockets; that
is, a single initiator socket may be bound to multiple target sockets, and a si ngl e target socket may
be bound to mul ti pl e initiator sockets. The two cl ass templates have templ ate parameters speci fyi ng
the number of bindings and the port binding pol icy, which are used withi n the cl ass i mpl ementation
to parameteri ze the associ ated sc_port templ ate i nstanti ati on.
s) I f an object of cl ass tlm_base_initiator _socket or tlm_base_tar get_socket i s bound mul ti pl e
ti mes, then the method oper ator [] can be used to address the corresponding object to which the
socket is bound. The index value i s determi ned by the order i n whi ch the methods bind or
oper ator () were call ed to bind the sockets. However, any incoming interface method cal ls recei ved
by such a socket wi ll be anonymous in the sense that there is no mechanism provided to identif y the
cal ler. On the other hand, such a mechani sm is provided by the conveni ence sockets (see 16.1.4).
t) For example, consi der a socket bound to two separate targets. The cal ls socket[0]-
>nb_tr anspor t_fw(...) and socket[1]->nb_tr anspor t_fw() would address the two targets, but there
is no way to i denti fy the call er of i n incoming nb_tr ansport_bw() method f rom one of those two
targets.
u) The i mplementati ons of the virtual methods get_base_por t and get_base_export shall return the
port and export obj ects of the socket, respectively. The impl ementati on of the virtual method
get_base_inter face shall return the export obj ect i n the case of the i ni ti ator port, or the socket obj ect
itsel f i n the case of the target socket.
13.2.5 Classes tlm_initiator_socket and tlm_target_socket
a) The socket tlm_initiator _socket and tlm_tar get_socket take a protocol trai ts class as a template
parameter. These sockets (or convenience sockets derived from them) shoul d typi call y be used by an
appl ication rather than the base sockets.
b) The constructors of the cl asses tlm_initiator_socket and tlm_tar get_socket shall call the
correspondi ng constructors of thei r respecti ve base cl asses, passing the char * argument where it
exists.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


462
Copyright 2012 IEEE. All rights reserved.
c) I n order f or two sockets of classes tlm_initiator _socket and tlm_tar get_socket to be bound
together, they must share the same protocol traits class (default tlm_base_protocol_types) and bus
wi dth. Strong type checki ng between sockets can be achieved by defi ni ng a new protocol traits class
f or each di stinct protocol, whether or not that protocol i s based on the generic payload.
d) The method kind shall return the class name as a C string, that is, "tlm_i nitiator_socket" or
"tl m_target_socket", respecti vel y.
Exampl e:
#include <systemc>
#include "tlm.h"
usi ng namespace sc_core;
usi ng namespace std;
struct I nitiator: sc_module, tl m::tl m_bw_transport_if <> // I nitiator i mplements the bw i nterf ace
{
tl m::tlm_ini ti ator_socket<32> i nit_socket; // Protocol types default to base protocol
SC_CTOR(Initiator) : i nit_socket("ini t_socket") {
SC_THREAD(thread);
ini t_socket.bind( * thi s ); // I nitiator socket bound to the i ni ti ator i tsel f
}
void thread() { // Process generates one dummy transaction
tl m::tlm_generic_payload trans;
sc_time del ay = SC_ZERO_TIME;
ini t_socket->b_transport(trans, delay);
}
virtual tlm::tlm_sync_enum nb_transport_bw(
tl m::tlm_generic_payload& trans,
tl m::tlm_phase& phase,
sc_core::sc_ti me& t) {
return tl m::TLM_COMPLETED; // Dummy i mplementati on
}
virtual void inval idate_direct_mem_ptr(sc_dt::uint64 start_range, sc_dt::uint64 end_range)
{ } // Dummy impl ementation
} ;
struct Target: sc_module, tlm::tl m_fw_transport_i f<> // Target i mplements the f w interface
{
tl m::tlm_target_socket<32> targ_socket; // Protocol types default to base protocol
SC_CTOR(Target) : targ_socket("targ_socket") {
targ_socket.bind( * thi s ); // Target socket bound to the target i tself
}
virtual tl m::tlm_sync_enum nb_transport_fw(
tl m::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_core::sc_ti me& t) {
return tl m::TLM_COMPLETED; // Dummy i mplementati on
}
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


463
Copyright 2012 IEEE. All rights reserved.
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_ti me& del ay )
{ } // Dummy impl ementation
virtual bool get_di rect_mem_ptr(tl m::tlm_generic_payload& trans, tlm::tlm_dmi& dmi_data)
{ return fal se; } // Dummy impl ementation
virtual unsi gned int transport_dbg(tlm::tlm_generi c_payl oad& trans)
{ return 0; } // Dummy impl ementation
} ;
SC_MODULE(Top1) // Showing a simple non-hierar chical binding of initiator to tar get
{
Ini ti ator * init;
Target * targ;
SC_CTOR(Top1) {
ini t = new I nitiator("i ni t");
targ = new Target("targ");
ini t->init_socket.bi nd(targ->targ_socket); // Bind ini tiator socket to target socket
}
} ;
struct Parent_of _i nitiator: sc_module // Showing hier archical socket binding
{
tl m::tlm_ini ti ator_socket<32> i nit_socket;
Ini ti ator* initiator;
SC_CTOR(Parent_of_i nitiator) : i nit_socket("ini t_socket") {
ini ti ator = new I nitiator("ini ti ator");
ini ti ator->init_socket.bi nd( init_socket ); // Bi nd i nitiator socket to parent i nitiator socket
}
} ;
struct Parent_of _target: sc_modul e
{
tl m::tlm_target_socket<32> targ_socket;
Target* target;
SC_CTOR(Parent_of_target) : targ_socket("targ_socket") {
target = new Target("target");
targ_socket.bind( target->targ_socket ); // Bi nd parent target socket to target socket
}
} ;
SC_MODULE(Top2)
{
Parent_of_ini tiator * init;
Parent_of_target * targ;
SC_CTOR(Top2) {
ini t = new Parent_of _i nitiator("i ni t");
targ = new Parent_of _target("targ");
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


464
Copyright 2012 IEEE. All rights reserved.
ini t->init_socket.bi nd(targ->targ_socket); // Bind ini ti ator socket to target socket at top l evel
}
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


465
Copyright 2012 IEEE. All rights reserved.
14. TLM-2.0 generic payload
14.1 Introduction
Thegeneri c payl oad i sthecl asstypeoffered by theTLM-2.0standard for transaction obj ectspassed through
the core interfaces. The generi c payload is cl osely rel ated to thebase protocol , whi ch i tsel f defi nes further
rul esto ensurei nteroperabi li ty whenusing thegeneric payl oad (see15.2).
The generi c payload is intended to improve the i nteroperabi li ty of memory-mapped bus model s, whi ch it
does at two level s. Fi rst, the generic payl oad provides an off-the-shelf general -purpose payl oad that
guarantees immediate i nteroperabili ty when creati ng abstract models of memory-mapped buses where the
precise detai ls of the bus protocol are unimportant, whi le at the same ti me providi ng an extension
mechanism for i gnorabl e attributes. Second, the generic payload can be used as the basi s for creati ng
detail ed models of specific bus protocol s, with the advantage of reducing the impl ementation cost and
increasi ng si mulati on speed when thereisaneed to bridgeor adapt between di fferent protocol s, someti mes
to thepoint wherethebri dgebecomestri vi al to write.
The generi c payl oad i s specifical ly ai med at model ing memory-mapped buses. It includes some attributes
found i n typi cal memory-mapped busprotocol ssuch as command, address, data, byteenables, si ngleword
transfers, burst transfers, streami ng, and responsestatus. Thegeneri c payl oad may al so beused asthebasi s
for model ing protocols other thanmemory-mapped buses.
Thegeneri c payload does not includeevery attributefound i n typical memory-mapped busprotocol s, but it
does includean extension mechanismsothat appl icationscan add thei r own speciali zed attri butes.
For speci fi c protocols, whether bus-based or not, modeling and interoperabil ity aretheresponsi bi li ty of the
protocol ownersand areoutsidethescopeof theAccell eraSystemsInitiati ve. It isup to theprotocol owners
or subject matter experts to prol iferate model s or codi ng gui deli nes for their own parti cular protocol.
However, thegeneric payload i ssti ll appli cablehere, becauseit providesacommonstarti ngpoint for model
creati on, and in many cases wi ll reduce the cost of bri dgi ng between different protocols in a transaction-
level model .
It isrecommendedthat thegeneri c payl oad beused wi th thei nitiator andtarget sockets, whi chprovideabus
wi dth parameter used when i nterpreting the data array of the generi c payl oad as well as forward and
backward paths and a mechani sm to enforce strong type checking between di fferent protocols whether or
not they arebased onthegeneric payload.
Thegeneric payloadcanbeused with both theblocking and non-blocking transport interfaces. It can al so be
used wi th thedirect memory and debug transport i nterfaces, i n which caseonly arestri cted set of attributes
isused.
14.2 Extensions and interoperability
Thegoal of thegeneric payl oad is to enabl ei nteroperabil ity between memory-mapped bus models, but all
buses are not created equal . Given two transaction-l evel model sthat usedifferent protocolsand that model
those protocols at a detai led level, then just as in aphysical system, an adapter or bridge must be inserted
between thosemodelsto performprotocol conversi on and all ow themto communicate. On the other hand,
many transaction level models producedearly in thedesign flow donot careabout thespeci fi c detail sof any
parti cul ar protocol . For such modelsi t i ssuffi cient to copy ablock of datastarting at agivenaddress, and for
thosemodels, thegeneric payl oad can beuseddirectly to giveexcellent i nteroperabil ity.
Thegeneri c payl oad extensi on mechanismpermitsany number of extensi onsof any typeto be defined and
added to a transaction obj ect. Each extensi on representsa new set of attributes, transported al ong wi th the
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


466
Copyright 2012 IEEE. All rights reserved.
transaction obj ect. Extensions can be created, added, wri tten and read by i nitiators, interconnect
components, and targets ali ke. The extension mechanism itself does not impose any restri ctions. Of course,
undi sci pl ined use of thi s extension mechanism woul d compromi se i nteroperabil ity, so discipli ned use i s
strongly encouraged. But the f lexi bil ity is there where you need i t!
The use of the extension mechani sm represents a trade-off between increased codi ng conveni ence when
binding sockets, and decreased compil e-time type checking. I f the undi sci pl ined use of generi c payload
extensi ons were all owed, each appli cation would be obl iged to detect any incompatibil ity between
extensions by i ncl udi ng expl icit run-ti me checks in each interconnect component and target, and there
would be no mechani sm to enf orce the exi stence of a gi ven extension. The TLM-2.0 standard prescri bes
specif ic codi ng guideli nes to avoi d these pi tf alls.
There are three, and only three, recommended al ternati ves for the transacti on template argument TRANS of
the blocking and non-blocki ng transport i nterf aces and the template argument TYPES of the combined
interfaces:
a) Use the generic payl oad directly, with ignorable extensions, and obey the rul es of the base protocol.
Such a model is said to be TLM-2.0 base-protocol-compl iant (see 9.1).
b) Defi ne a new protocol traits class contai ning a typedef for tlm_gener ic_payload. Such a model is
sai d to be TLM-2.0 custom-protocol-compl iant (see 9.1).
c) Defi ne a new protocol trai ts cl ass and a new transaction type. Such a model may use i sol ated
f eatures of the TLM-2.0 class l ibrary but i s nei ther TLM-2.0 base-protocol -compli ant nor TLM-2.0
custom-protocol-compliant (see 9.1).
These three al ternati ves are def ined below in order of decreasi ng i nteroperabi li ty.
I t should be emphasized that al though deri vi ng a new class f rom the generi c payl oad i s possible, it is not the
recommended approach for i nteroperabi li ty
I t shoul d also be emphasized that these three options may be mi xed i n a single system model. I n parti cul ar,
there is value i n mi xi ng the f irst two options si nce the extensi on mechanism has been designed to permit
eff icient i nteroperabi li ty.
14.2.1 Use the generic payload directly, with ignorable extensions
a) I n thi s case, the transaction type i s tlm_gener ic_payload, the phase type i s tlm_phase, and the
protocol traits cl ass f or the combined interfaces is tlm_base_protocol_types. These are the def aul t
values f or the TRANS argument of the transport interfaces and TYPES argument of the combi ned
interfaces, respecti vel y. Any model that uses the standard i niti ator and target sockets wi th the base
protocol wi ll be i nteroperabl e wi th any other such model , provided that those model s respect the
semanti cs of the generic payload and the base protocol (see 15.2).
b) I n this case, any generi c payload extensi on or extended phase shal l be i gnorabl e. Ignorabl e means
that any component other than the component that added the extensi on i s permi tted to behave as i f
the extension were absent (see 14.21.1.1).
c) I f an extensi on i s ignorable, then by def ini ti on compil e-ti me checki ng to enf orce support f or that
extensi on i n a target i s not wanted, and indeed, the ignorabl e extension mechani sm does not support
compile-ti me checki ng.
d) The generi c payload intrinsicall y supports mi nor variati ons i n protocol . As a general princi ple, a
target i s recommended to support every f eature of the generic payload. But, f or exampl e, a particular
component may or may not support byte enabl es. A target that i s unable to support a particul ar
f eature of the generic payload is obliged to generate the standard error response. This should be
thought of as being part of the specif ication of the generic payload.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


467
Copyright 2012 IEEE. All rights reserved.
14.2.2 Define a new protocol traits class containing a typedef for tlm_generic_payload
a) I n this case, the transacti on type i s tlm_gener ic_payload and the phase type tlm_phase, but the
protocol traits class used to speci ali ze the socket i s a new appl ication-def ined class, not the default
tlm_base_protocol_types. This ensures that the extended generic payload is treated as a di stinct
type and provides compil e-ti me type checking when the i ni ti ator and target sockets are bound.
b) The new protocol type may set i ts own rul es, and these rul es may extend or contradict any of the
rul es of the base protocol, including the generi c payl oad memory management rules (see 14.5) and
the rules for the modifi abi li ty of attri butes (see 14.7). However, f or the sake of consistency and
interoperabi li ty, i t i s recommended to foll ow the rules and coding style of the base protocol as f ar as
possibl e (see 15.2).
c) The generi c payl oad extensi on mechanism may be used for ignorable, non-i gnorable, or mandatory
extensi ons with no restrictions. The semanti cs of any extensi ons should be thoroughl y documented
wi th the new protocol traits cl ass.
d) Because the transacti on type i s tlm_gener ic_payload, the transaction can be transported through
interconnect components and targets that use the generi c payl oad type, and can be cl oned i n i ts
entirety, including all extensions. Thi s provi des a good starting point f or buil ding interoperable
components and f or creating adapters or bridges between di ff erent protocols, but the user should
consider the semanti cs of the extended generi c payload very caref ull y.
e) I t i s usual to use one and the same protocol traits class al ong the entire length of the path fol lowed by
a transaction from an ini ti ator through zero or more interconnect components to a target. However, i t
may be possi bl e to model an adapter or bus bridge as an i nterconnect component that takes incoming
transactions of one protocol type and converts them to outgoi ng transacti ons of another protocol
type. I t is also possi bl e to create a transacti on bridge, which acts as a target f or incoming
transactions and as an i niti ator f or outgoing transacti ons.
f ) When passing a generi c payload transaction between sockets speci al ized usi ng di ff erent protocol
traits classes, the user i s obl iged to consider the semantics of each extensi on very caref ul ly to ensure
that the transaction can be transported through components that are aware of the generi c payload but
not the extensions. There is no general rule. Some extensi ons can be transported through
components i gnorant of the extension without mi shap, for exampl e, an attri bute specif ying the
securi ty level of the data. Other extensi ons wil l require expl icit adaption or might not be supportable
at all , for exampl e, an attribute specif ying that the interconnect i s to be locked.
14.2.3 Define a new protocol traits class and a new transaction type
a) I n this case, the transaction type may be unrel ated to the generic payload.
b) A new protocol trai ts cl ass wi ll need to be defi ned to parameteri ze the combined i nterf aces and the
sockets.
c) This choice may be j ustif ied when the new transacti on type is signif icantly diff erent from the
generic payload or represents a very speci fi c protocol.
d) I f the intenti on i s to use the generi c payl oad for maxi mal interoperabi lity, the recommended
approach is to use the generic payload as described in one of the previous two clauses rather than to
use it in the def ini tion of a new class.
14.3 Generic payload attributes and methods
The generi c payload class contains a set of private attributes, and a set of publ ic access f unctions to get and
set the values of those attri butes. The exact impl ementati on of those access f uncti ons is impl ementation-
def ined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


468
Copyright 2012 IEEE. All rights reserved.
The majority of the attri butes are set by the initiator and shall not be modif ied by any interconnect
component or target. Only the address, DMI all owed, response status and extension attributes may be
modif ied by an interconnect component or by the target. I n the case of a read command, the target may also
modif y the data array.
14.4 Class definition
namespace tl m {
class tl m_generi c_payload;
class tlm_mm_inter face {
publ ic:
virtual void free(tlm_generic_payl oad* ) = 0;
virtual ~tlm_mm_inter face() { }
} ;
unsi gned int max_num_extensions();
class tlm_extension_base
{
publ ic:
virtual tlm_extension_base* clone() const = 0;
virtual void free() { delete this; }
virtual void copy_from(tlm_extension_base const & ) = 0;
protected:
virtual ~tlm_extension_base() { }
} ;
templ ate <typename T>
class tlm_extension : publi c tlm_extensi on_base
{
publ ic:
virtual tlm_extension_base* clone() const = 0;
virtual void copy_from(tlm_extension_base const & ) = 0;
virtual ~tlm_extension() { }
const stati c unsigned i nt I D;
} ;
enum tlm_gp_option {
TLM_MIN_PAYLOAD,
TLM_FULL_PAYLOAD,
TLM_FULL_PAYLOAD_ACCEPTED
} ;
enum tlm_command {
TLM_READ_COMMAND,
TLM_WRITE_COMMAND,
TLM_I GNORE_COMMAND
} ;
enum tlm_response_status{
TLM_OK_RESPONSE = 1,
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


469
Copyright 2012 IEEE. All rights reserved.
TLM_I NCOMPLETE_RESPONSE = 0,
TLM_GENERIC_ERROR_RESPONSE = 1,
TLM_ADDRESS_ERROR_RESPONSE = 2,
TLM_COMMAND_ERROR_RESPONSE = 3,
TLM_BURST_ERROR_RESPONSE = 4,
TLM_BYTE_ENABLE_ERROR_RESPONSE = 5
} ;
#def ine TLM_BYTE_DISABLED 0x0
#def ine TLM_BYTE_ENABLED 0xff
class tlm_gener ic_payload {
publ ic:
// Constructors and destructor
tlm_gener ic_payload();
expl icit tlm_gener ic_payload( tlm_mm_interface* );
virtual ~tlm_gener ic_payload();
pri vate:
// Disable copy constructor and assignment operator
tl m_generi c_payload( const tl m_generi c_payl oad& );
tl m_generi c_payload& oper ator = ( const tl m_generi c_payl oad& );
publ ic:
// Memory management
void set_mm( tlm_mm_interface* );
bool has_mm() const;
void acquire();
void release();
int get_ref_count() const;
void reset();
void deep_copy_fr om( const tl m_generic_payl oad & );
void ( const tlm_generic_payl oad & , bool use_byte_enable_on_read = true );
void update_extensions_from( const tl m_generi c_payl oad & );
void free_all_extensions();
// Access methods
tl m_gp_opti on get_gp_option() const;
void set_gp_option( const tl m_gp_opti on );
tl m_command get_command() const;
void set_command( const tl m_command );
bool is_read();
void set_read();
bool is_wr ite();
void set_write();
sc_dt::uint64 get_addr ess() const;
void set_addr ess( const sc_dt::uint64 );
unsi gned char* get_data_ptr () const;
void set_data_ptr( unsigned char* );
unsi gned int get_data_length() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


470
Copyright 2012 IEEE. All rights reserved.
void set_data_length( const unsigned i nt );
unsi gned int get_streaming_width() const;
void set_streaming_width( const unsigned i nt );
unsi gned char* get_byte_enable_ptr () const;
void set_byte_enable_ptr( unsigned char* );
unsi gned int get_byte_enable_length() const;
void set_byte_enable_length( const unsigned i nt );

// DMI hint
void set_dmi_allowed( bool );
bool is_dmi_allowed() const;
tl m_response_status get_response_status() const;
void set_response_status( const tl m_response_status );
std::stri ng get_response_str ing();
bool is_response_ok();
bool is_response_er ror();
// Extensi on mechanism
templ ate <typename T> T* set_extension( T* );
tl m_extension_base* set_extension( unsigned i nt , tlm_extensi on_base* );
templ ate <typename T> T* set_auto_extension( T* );
tl m_extension_base* set_auto_extension( unsigned i nt , tlm_extensi on_base* );
templ ate <typename T> void get_extension( T* & ) const;
templ ate <typename T> T* get_extension() const;
tl m_extension_base* get_extension( unsigned i nt ) const;
templ ate <typename T> void clear_extension( const T* );
templ ate <typename T> void clear_extension();
templ ate <typename T> void release_extension( T* );
templ ate <typename T> void release_extension();
void resize_extensions();
} ;
} // namespace tl m
14.5 Generic payload memory management
a) The i niti ator shal l be responsi bl e for setti ng the data poi nter and byte enable poi nter attri butes to
exi sti ng storage, which coul d be stati c, automatic (stack), or dynami cal ly al located (new) storage.
The i ni ti ator shal l not del ete thi s storage bef ore the li feti me of the transacti on i s complete. The
generic payload destructor does not del ete these two arrays.
b) This cl ause should be read in conj uncti on wi th the rul es on generic payl oad extensions (see 14.21).
c) The generic payl oad supports two di stinct approaches to memory management; ref erence counti ng
wi th an expli cit memory manager and ad hoc memory management by the ini ti ator. The two
approaches can be combi ned. Any memory management approach should manage both the
transaction obj ect itself and any extensi ons to the transaction obj ect.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


471
Copyright 2012 IEEE. All rights reserved.
d) The construction and destruction of objects of type tlm_gener ic_payload is expected to be
expensi ve in terms of CPU ti me due to the i mplementation of the extensi on array. As a consequence,
repeated constructi on and destruction of generic payl oad obj ects shoul d be avoi ded. There are two
recommended strategies; ei ther use a memory manager that i mpl ements a pool of transaction
objects, or i f using ad hoc memory management, reuse the very same generi c payload object across
successive calls to b_tr anspor t (eff ectively a transacti on pool wi th a si ze of one). I n particular,
havi ng a generi c payload object constructed and destructed once per cal l to transport would be
prohibi ti vel y slow and shoul d be avoi ded.
e) A memory manager i s a user-def ined class that i mplements at l east the free method of the abstract
base class tlm_mm_inter face. The intent is that a memory manager woul d provide a method to
all ocate a generic payload transaction object f rom a pool of transactions, woul d i mplement the free
method to return a transaction object to that same pool, and woul d impl ement a destructor to delete
the enti re pool. The free method is call ed by the release method of cl ass tlm_gener ic_payload
when the ref erence count of a transaction obj ect reaches 0. The free method of cl ass
tlm_mm_inter face would typicall y call the reset method of class tlm_gener ic_payload in order to
del ete any extensions marked f or automati c deleti on.
f ) The methods set_mm, acquire, release, get_ref_count, and reset of the generi c payload shall only
used in the presence of a memory manager. By def aul t, a generic payload object does not have a
memory manager set.
g) Ad hoc memory management by the ini ti ator wi thout a memory manager requi res the ini ti ator to
all ocate memory f or the transacti on object bef ore the TLM-2.0 core interface cal l, and del ete or pool
the transaction obj ect and any extension obj ects af ter the cal l.
h) When the generic payl oad is used with the bl ocki ng transport interface, the direct memory interface
or the debug transport interface, either approach may be used. Ad hoc memory management by the
ini ti ator i s suff icient. I n the absence of a memory manager, the b_tr anspor t, get_direct_mem_ptr,
or transpor t_dbg method should assume that the transacti on object and any extensi ons wi ll be
invali dated or deleted on return.
i) When the generi c payl oad i s used wi th the non-blocking transport i nterface, a memory manager
shal l be used. Any transaction obj ect passed as an argument to nb_transpor t shal l have a memory
manager al ready set. This appli es whether the cal ler is the initiator, an i nterconnect component, or a
target.
j ) A bl ocking-to-non-blocking transport adapter shal l set a memory manager for a given transacti on if
none existed al ready, in whi ch case it shall remove that same memory manager f rom the transaction
bef ore returning control to the caller. A memory manager cannot be removed until the ref erence
count has returned to 0, so the impl ementati on wil l necessari ly require that the method free of the
memory manager does not del ete the transacti on object. The simple_tar get_socket provides an
exampl e of such an adapter.
k) When using a memory manager, the transaction object and any extension objects shal l be al located
f rom the heap (ultimately by call ing new or malloc).
l ) When usi ng ad hoc memory management, the transacti on object and any extensi ons may be
all ocated from the heap or f rom the stack. When using stack al location, parti cul ar care needs to be
taken wi th the memory management of extensi on obj ects i n order to avoi d memory leaks and
segmentati on f aul ts.
m) The method set_mm shall set the memory manager of the generic payl oad obj ect to the obj ect
whose address i s passed as an argument. The argument may be null , in whi ch case any existi ng
memory manager would be removed from the transaction object, but not i tsel f del eted. set_mm
shal l not be call ed f or a transacti on object that al ready has a memory manager and a reference count
greater than 0.
n) The method has_mm shall return true i f and onl y if a memory manager has been set. When call ed
f rom the body of an nb_transport method, has_mm should return true.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


472
Copyright 2012 IEEE. All rights reserved.
o) When call ed from the body of the b_tr ansport, get_dir ect_mem_ptr , or transpor t_dbg methods,
has_mm may return true or false. An i nterconnect component may call has_mm and take the
appropriate action depending on whether or not a transaction has a memory manager. Otherwise, i t
shal l assume al l the obl igations of a transacti on wi th a memory manager (for example, heap
all ocati on), but shal l not call any of the methods that require the presence of a memory manager (for
exampl e, acquire).
p) Each generic payload obj ect has a ref erence count. The default val ue of the ref erence count i s 0.
q) The method acquire shal l i ncrement the val ue of the reference count. I f acquire i s call ed i n the
absence of a memory manager, a run-time error wi ll occur.
r) The method release shall decrement the value of the ref erence count, and i f thi s leaves the value
equal to 0, shal l call the method free of the memory manager obj ect, passi ng the address of the
transaction object as an argument. I f release is cal led in the absence of a memory manager, a run-
ti me error wil l occur.
s) The method get_ref_count shall return the val ue of the reference count. I n the absence of a memory
manager, the val ue returned woul d be 0.
t) I n the presence of a memory manager, each ini ti ator shoul d call the acquire method of each
transaction obj ect before fi rst passi ng that object as an argument to an i nterface method call , and
shoul d call the release method of that transaction object when the object i s no longer requi red.
u) I n the presence of a memory manager, each interconnect component and target should call the
acquire method whenever they need to extend the li feti me of a transacti on object beyond the current
interface method cal l, and call the release method when the obj ect is no longer required.
v) I n the presence of a memory manager, a component may cal l the release method from any i nterf ace
method cal l or process. Thus, a component cannot assume a transaction object i s sti ll val id af ter
making an interf ace method cal l or after yieldi ng control unless it has previousl y cal led the acquire
method. For exampl e, an initiator may cal l releasef rom its i mplementati on of nb_tr ansport_bw, or
a target f rom i ts i mplementati on of nb_tr anspor t_fw.
w) I f an i nterconnect component or a target wi shes to extend the li fetime of a transaction object
indefi nitel y for anal ysis purposes, i t should make a clone of the transaction object rather than usi ng
the ref erence counti ng mechani sm. In other words, the reference count should not be used to extend
the li feti me of a transacti on object beyond the normal phases of the protocol.
x) I n the presence of a memory manager, a transaction obj ect shal l not be reused to represent a new
transaction or reused wi th a di ff erent i nterf ace until the ref erence count i ndicates that no component
other than the i ni ti ator itself sti ll has a reference to the transaction object. That is, assuming the
ini ti ator has cal led acquire f or the transaction object, unti l the reference count equals 1. This rul e
appl ies when reusi ng transactions with the same interface or across the transport, di rect memory,
and debug transport interfaces. When reusi ng transaction objects to represent di ff erent transacti on
instances, i t is best practice not to reuse the obj ect unti l the ref erence count equal s 0, that i s, until the
object has been freed.
y) The method reset shall delete any extensions marked for automati c deleti on, and shal l set the
corresponding extension pointers to null . Each extension shall be del eted by cal li ng the method free
of the extensi on obj ect, which could conceivably be overloaded if a user wi shed to provide expl icit
memory management for extensi on objects. The method reset shal l set the val ue of the opti on
attri bute to TLM_MIN_PAYLOAD. The method reset should typicall y be cal led f rom the method
free of class tlm_mm_inter face i n order to delete extensi ons at the end of the l if etime of a
transaction.
z) An extensi on obj ect added by call ing set_extension may be del eted by call ing release_extension.
Call ing clear_extension would only clear the extensi on pointer, not delete the extension object
itsel f. This l atter behavior would be required in the case that transacti on objects are stack-all ocated
wi thout a memory manager, and extension obj ects pooled.
aa) I n the absence of a memory manager, whi chever component all ocates or sets a given extension
should al so delete or cl ear that same extension before returni ng control f rom b_tr anspor t,
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


473
Copyright 2012 IEEE. All rights reserved.
get_dir ect_mem_ptr , or transpor t_dbg. For exampl e, an i nterconnect component that i mplements
b_tr anspor t and cal ls set_mm to add a memory manager to a transaction obj ect shal l not return
f rom b_tr anspor t unti l i t has removed f rom the transaction obj ect all extensions added by i tself
(and assumi ng that any downstream components wi ll already have removed any extensions added
by themselves, by vi rtue of this very same rule).
ab) I n the presence of a memory manager, extensi ons can be added by call ing set_auto_extension, and
thus deleted or pooled automatical ly by the memory manager. Alternatively, extensions added by
cal li ng set_extension and not expl icitly cl eared are so-cal led sti cky extensions, meani ng that they
wi ll not be automaticall y deleted when the transacti on reference count reaches 0 but may remain
associ ated wi th the transacti on object even when it i s pool ed. Sticky extensi ons are a parti cul arl y
eff icient way to manage extensi on obj ects because the extensi on obj ect need not be deleted and
reconstructed between transport call s. Sti cky extensions rel y on transacti on obj ects bei ng pool ed (or
reused singly).
ac) I f it i s unknown whether or not a memory manager i s present, extensi ons should be added by cal ling
set_extension and deleted by cal li ng release_extension. This cal li ng sequence i s safe in the
presence or absence of a memory manager. This ci rcumstance can onl y occur wi thi n an i nterconnect
component or target that chooses not to cal l has_mm. (Within an ini tiator, it i s always known
whether or not a memory manager i s present, and a call to has_mm wi ll al ways reveal whether or
not a memory manager i s present.)
ad) The method free_all_extensions shal l delete all extensions, i ncl udi ng but not li mited to those
marked for automati c deleti on, and shal l set the corresponding extensi on pointers to null . Each
extension shall be del eted by call ing the method free of the extension object. The free method coul d
conceivabl y be overl oaded i f a user wished to provi de expl icit memory management f or extensi on
objects.
ae) free_all_extensions would be useful when removi ng the extensions f rom a pooled transacti on
object that does not use a memory manager. Wi th a memory manager, extensions marked for
automati c del etion woul d indeed have been deleted automati cal ly, whi le sti cky extensi ons woul d not
need to be deleted.
af) The method deep_copy_fr om shal l modif y the attributes and extensi ons of the current transaction
object by copying those of another transacti on object, whi ch is passed as an argument to the method.
The opti on, command, address, data l ength, byte enable length, streaming width, response status,
and DMI all owed attri butes shal l be copi ed. The data and byte enabl e arrays shal l be deep copied if
and only if the correspondi ng pointers i n both transactions are non-null. The appli cati on i s
responsibl e for ensuring that the arrays i n the current transacti on are suf fi ciently large. I f an
extension on the other transaction already exi sts on the current transacti on, it shall be copi ed by
cal li ng the copy_from method of the extensi on class. Otherwise, a new extension obj ect shal l be
created by call ing the clone method of the extensi on cl ass, and set on the current transaction. In the
case of cl oning, the new extension shall be marked f or automati c deleti on i f and onl y i f a memory
manager i s present for the current transaction.
ag) I n other words, in the presence of a memory manager deep_copy_from wi ll mark f or automati c
del eti on any new extensi ons that were not al ready on the current obj ect. Without a memory
manager, extensi ons cannot be marked for auto-deleti on.
ah) The method update_or iginal_fr om shall modi fy certain attributes and extensions of the current
transaction obj ect by copyi ng those of another transaction object, which is passed as an argument to
the method. The i ntent i s that update_or iginal_fr om shoul d be cal led to pass back the response for
a transacti on created using deep_copy_from. The response status and DMI all owed attributes of the
current transaction obj ect shal l be modif ied. The data array shal l be deep copi ed i f and onl y if the
command attribute of the current transaction i s TLM_READ_COMMAND and the data poi nters i n
the two transactions are both non-null and are unequal. The byte enable array shal l be used to mask
the copy operati on, as per the read command, if and only if the byte enabl e pointer i s non-null and
the use_byte_enable_on_r ead argument i s true. Otherwise, the entire data array shal l be deep
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


474
Copyright 2012 IEEE. All rights reserved.
copi ed. The extensions of the current transaction object shal l be updated as per the
update_extensions_from method.
ai) The method update_extensions_from shall modif y the extensions of the current transaction obj ect
by copying f rom another transacti on object only those extensions that were already present on the
current object. The extensions shal l be copi ed by calli ng the copy_from method of the extension
class.
aj) The typi cal use case f or deep_copy_fr om, update_or iginal_from, and update_extensions_from
is withi n a transaction bridge where they are used to deep copy an incoming request, send the copy
out through an i ni ti ator socket, then on receiving back the response copy the appropriate attri butes
and extensions back to the original transaction object. The transacti on bri dge may choose to deep
copy the arrays or merely to copy the pointers.
ak) These obl igati ons appl y to the generic payl oad. I n principl e, similar obl igati ons mi ght appl y to
transaction types unrelated to the generi c payload
14.6 Constructors, assignment, and destructor
a) The default constructor shal l set the generi c payl oad attributes to thei r default values, as def ined in
the fol lowing clauses.
b) The constructor tlm_gener ic_payload( tlm_mm_interface* ) shall set the generi c payload
attri butes to their def aul t values, and shal l set the memory manager of the generi c payload obj ect to
the obj ect whose address i s passed as an argument. Thi s is equi val ent to call ing the def aul t
constructor and then immedi ately cal li ng set_mm.
c) The copy constructor and assi gnment operators are di sabled.
d) The virtual destructor ~tlm_gener ic_payload shal l delete all extensions, including but not limited
to those marked for automatic deleti on. Each extension shall be del eted by call ing the method free
of the extensi on object. The destructor shal l not del ete the data array or the byte enable array.
14.7 Default values and modifiability of attributes
The def aul t values and modi fi abi li ty of the generic payl oad attributes and arrays for the base protocol are
summari zed in Tabl e 54 and Tabl e 55:
a) I t is the responsibil ity of the i nitiator to set the val ues of the generi c payl oad attributes pri or to
passing the transaction object through an interf ace method cal l accordi ng to the rul es of the core
interf ace being used. I n the case of the transport interfaces, every generic payload attri bute shall be
set wi th the exception of the extension pointers. The DMI and debug transport i nterf aces have thei r
own rul es, descri bed in 11.2.4 and 11.3.4, respecti vel y. The opti on attribute can be used to
determi ne whether the DMI and debug transport interfaces use a minimal or a f ull set of generic
playload attri butes. Care shoul d be taken to ensure the attri butes are set correctly in the case where
transaction objects are pool ed and reused.
b) I n the case that a transacti on object is returned to a pool or otherwi se reused, these modi fi abi li ty
rul es cease to apply at the end of the l if etime of that transacti on i nstance. I n the presence of a
memory manager, this i s the poi nt at which the ref erence count reaches 0 or, otherwi se, on return
f rom the i nterf ace method call . The modi fi abi li ty rules would apply afresh i f the transaction object
was reused f or a new transacti on.
c) Af ter passi ng the transaction object as an argument to an i nterf ace method call (b_tr anspor t,
nb_tr anspor t_fw, get_dir ect_mem_ptr, or tr anspor t_dbg), the only generi c payl oad attributes
that the ini tiator i s permitted to modi fy duri ng the li feti me of the transaction are the extension
pointers.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


475
Copyright 2012 IEEE. All rights reserved.
d) An i nterconnect component i s permitted to modif y the address attri bute, but onl y bef ore passi ng the
transaction concerned as an argument to any TLM-2.0 core interface method on the f orward path.
Once an interconnect component has passed a ref erence to the transaction to a downstream
component, it is not permi tted to modi fy the address attri bute of that transacti on object agai n
throughout the entire l if etime of the transacti on.
e) As a consequence of the previous rule, the address attribute is vali d immediatel y on entering any of
the f orward path i nterface method call s b_tr anspor t, get_dir ect_mem_ptr, or transpor t_dbg. I n
the case of nb_tr ansport_fw, the address attri bute i s vali d i mmediatel y on enteri ng the function but
only when the phase is BEGI N_REQ. Fol lowi ng the return from any f orward path TLM-2.0
interface method call , the address attri bute wi ll have the value set by the interconnect component
lyi ng f urthest downstream, and so shoul d be regarded as bei ng undefi ned f or the purposes of
transaction routi ng.
f ) The i nterconnect and target are not permi tted to modi fy the data array in the case of a wri te
command, but the target alone is permitted to modif y the data array in the case of a read command.
g) For a given transacti on object, the target i s permitted to modif y the DMI al lowed attribute, the
response status attribute, and (f or a read command) the data array at any ti me between having fi rst
received the transacti on obj ect and the time at whi ch i t passes a response i n the upstream directi on.
Table 54 Default values and modifiability of attributes
Attr ibute Default value M odifiable by
inter connect?
M odifiable by
tar get?
Opti on TLM_MI N_PAYLOAD No Yes
Command TLM_I GNORE_COMMAND No No
Address 0 Yes No
Data poi nter 0 No No
Data l ength 0 No No
Byte enabl e poi nter 0 No No
Byte enabl e l ength 0 No No
Streami ng width 0 No No
DMI all owed f alse Yes Yes
Response status TLM_I NCOMPLETE_RESPONSE No Yes
Extensi on poi nters 0 Yes Yes
Table 55Modifiability of generic payload arrays
Ar rays Default value M odifiable by
inter connect?
M odifiable by
tar get?
Data array - No Read command only
Byte enabl e array - No No
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


476
Copyright 2012 IEEE. All rights reserved.
A target i s not permitted to modi fy these attri butes af ter havi ng sent a response i n the upstream
direction. A target sends a response i n this sense whenever i t returns control f rom the b_tr anspor t,
get_dir ect_mem_ptr or transpor t_dbg methods, whenever it passes the BEGIN_RESP phase as
an argument to nb_transpor t, or whenever it returns the value TLM_COMPLETED from
nb_transpor t.
h) I f the DMI al lowed attri bute i s false, an interconnect component i s not permi tted to modify the DMI
all owed attribute. But i f the target sets the DMI al lowed attri bute to true, an i nterconnect component
is permitted to reset the DMI al lowed attri bute to false as i t passes the response i n an upstream
direction. I n other words, an interconnect component i s permi tted to clear the DMI all owed attribute,
despite the DMI all owed attri bute havi ng been set by the target.
i ) The i ni ti ator i s permitted to assume it i s seei ng the values of the DMI al lowed attri bute, the response
status attribute, and (f or a read command) the data array as modif ied by the target only after it has
received the response.
j ) I f the above rules permit a component to modif y the value of a transacti on attri bute wi thi n a
parti cul ar window of time, that attri bute may be modi fi ed at any time duri ng that window and any
number of times during that window. Any other component shall only read the value of the attribute
as i t is lef t at the end of the time wi ndow (with the excepti on of extensi ons).
k) The roles of i nitiator, interconnect, and target may change dynami call y. For exampl e, al though an
interconnect component is not permi tted to modif y the response status attribute, that same
component could modif y the response status attri bute by taki ng on the rol e of target f or a given
transaction. I n i ts role as a target, the component would be forbi dden f rom passing that parti cul ar
transaction any further downstream.
l) I n the case where the generi c payload i s used as the transacti on type for the direct memory and
debug transport i nterf aces, the modi fi abi li ty rul es given i n this secti on shal l appl y to the appropriate
attri butes, that i s, the command and address attributes i n the case of direct memory, and the
command, address, data pointer and data l ength attributes i n the case of debug transport.
14.8 Option attribute
a) The opti on attribute is used to determine whether the DMI and debug transport interf aces use a
mi ni mal or a f ul l set of generic payl oad attributes. The minimal set i s supported for backward
compatibil ity with previous versions of the TLM-2.0 standard. New components may choose to use
the mi ni mal or the f ull set of attri butes.
b) The method set_gp_option shall set the option attri bute to the val ue passed as an argument. The
method get_gp_option shal l return the current value of the option attribute.
c) The default val ue of the opti on attri bute shal l be TLM_MI N_PAYLOAD.
d) Wi th one exception, i nitiator, i nterconnect, and target components may ignore the option attri bute.
This appli es both to legacy components devel oped bef ore the publi cation of thi s standard and to new
components developed after the publi cati on of this standard. The one exception i s when an i ni ti ator
receives a transacti on wi th the option attribute havi ng the val ue
TLM_FULL_PAYLOAD_ACCEPTED.
e) When sendi ng a generi c payl oad transaction through the di rect memory i nterf ace, an i ni ti ator that
requires the target to set the response status attribute shal l set the opti on attribute to
TLM_FULL_PAYLOAD, in which case the initiator shal l set the val ues of the byte enable poi nter,
byte enable l ength, streaming wi dth, DMI al l owed, and response status attributes to thei r default
val ues (as gi ven in Tabl e 54).
f ) When sending a generic payload transaction through the debug transport i nterface, an i niti ator that
requires the target to use the byte enable poi nter, byte enabl e l ength, or streaming width attri butes or
that requi res the target to set the DMI al l owed or response status attributes shal l set the option
attri bute to TLM_FULL_PAYLOAD, in which case the i ni ti ator shal l set the DMI al l owed and
response status attri butes to their def ault val ues (as gi ven in Tabl e 54).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


477
Copyright 2012 IEEE. All rights reserved.
g) When a generic payload transaction is sent through the blocki ng or the non-blocking transport
interface, the option attri bute shall be set to TLM_MI N_PAYLOAD and shal l not be modif ied by
any component.
h) I f the option attribute has the val ue TLM_MIN_PAYLOAD, the value of the option attribute shall
not be modi fi ed by any interconnect or target component.
i) I n the case of the direct memory interface, i f the option attribute is TLM_MI N_PAYLOAD, the
target may i gnore the val ues of all attributes except the command and address attri butes.
j) I n the case of the di rect memory interface, if the opti on attribute i s TLM_FULL_PAYLOAD, the
target may set the value to TLM_FULL_PAYLOAD_ACCEPTED, in whi ch case the initiator and
the target shall set and act on the val ue of the response status attribute according to the rul es gi ven in
14.17.
k) In the case of the debug transport i nterf ace, if the opti on attri bute is TLM_MI N_PAYLOAD, the
target may ignore the values of the byte enabl e poi nter, byte enable l ength, streaming wi dth, DMI
al l owed, and response status attri butes.
l) I n the case of the debug transport i nterf ace, i f the option attribute is TLM_FULL_PAYLOAD, the
target may set the value to TLM_FULL_PAYLOAD_ACCEPTED, in whi ch case the initiator and
the target shall set and act on the values of the byte enabl e pointer, byte enable length, streami ng
wi dth, DMI al l owed, and response status attributes accordi ng to the rules given i n 14.13, 14.14,
14.15, 14.16, and 14.17, respecti vely.
m) I f the target chooses not to set the opti on attribute to TLM_FULL_PAYLOAD_ACCEPTED, the
target shall ignore the values of the byte enabl e pointer, byte enabl e l ength, and streami ng width
attri butes and shal l not set the DMI al l owed or response status attri butes.
n) I f the initiator sets the option attri bute to TLM_FULL_PAYLOAD and the target does not set the
opti on attribute to TLM_FULL_PAYLOAD_ACCEPTED, the initiator shal l assume that the target
has acted as if the option attribute were set to TLM_MI N_PAYLOAD. In this situation, i t i s possibl e
that the target may have wrongl y i nterpreted the generic payload attri butes; f or exampl e, the target
may have ignored the byte enable attributes for a debug transport transacti on.
o) An interconnect component shall not modi fy the value of the opti on attribute. (A component that
general ly acts as an i nterconnect component may act as a target component i n order to return an
error response, i n whi ch case it may set the val ue of the option attri bute to
TLM_FULL_PAYLOAD_ACCEPTED.)
p) An ini ti ator that sets the opti on attri bute to TLM_FULL_PAYLOAD shall ensure that the option
attri bute i s set back to TLM_MIN_PAYLOAD at the end of the lif etime of the transacti on object. I n
the presence of a memory manager, the method reset of cl ass tlm_gener ic_payload shall set the
opti on attri bute to TLM_MI N_PAYLOAD. I n the absence of a memory manager, the i nitiator is
obli ged to reset the option attribute expl icitly.
q) The value of the option attri bute shal l apply onl y to the current transacti on i nstance, and impl ies
nothing about the behavior of an ini ti ator, i nterconnect, or target with respect to other transacti ons or
to other i nterf aces. For example, a given i ni ti ator may set TLM_MIN_PAYLOAD and
TLM_FULL_PAYLOAD in two consecuti ve debug transport transacti ons, or may set
TLM_MI N_PAYLOAD i n a debug transport transacti on and TLM_FULL_PAYLOAD in a DMI
transaction. A target may set TLM_FULL_PAYLOAD_ACCEPTED for one transaction but not for
the next. Each component should inspect each transaction individuall y rather than bui ldi ng a map of
the ini ti ators and targets and their capabi li ti es.
14.9 Command attribute
a) The method set_command shal l set the command attri bute to the val ue passed as an argument. The
method get_command shall return the current value of the command attri bute.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


478
Copyright 2012 IEEE. All rights reserved.
b) The methods set_read and set_write shall set the command attri bute to TLM_READ_COMMAND
and TLM_WRI TE_COMMAND, respectively. The methods is_read and is_wr ite shal l return true
if and onl y if the current value of the command attri bute is TLM_READ_COMMAND and
TLM_WRITE_COMMAND, respectively.
c) A read command is a generic payl oad transacti on with the command attribute equal to
TLM_READ_COMMAND. A wri te command i s a generic payload transacti on with the command
attri bute equal to TLM_WRI TE_COMMAND. An i gnore command is a generi c payl oad transacti on
wi th the command attribute equal to TLM_IGNORE_COMMAND.
d) On receipt of a read command, the target shall copy the contents of a local array i n the target to the
array poi nted to be the data pointer attri bute, honori ng al l the semanti cs of the generic payload as
def ined by thi s standard.
e) On receipt of a wri te command, the target shal l copy the contents of the array pointed to by the data
pointer attribute to a local array in the target, honoring all the semanti cs of the generi c payload as
def ined by thi s standard.
f ) I f the target i s unable to execute a read or wri te command, it shal l generate a standard error response.
The recommended response status i s TLM_COMMAND_ERROR_RESPONSE.
g) An ignore command is a nul l command. The i ntent is that an ignore command may be used as a
vehi cl e f or transporting generi c payload extensions wi thout the need to execute a read or a wri te
command, although the rules concerni ng extensi ons are the same f or all three commands.
h) On recei pt of an i gnore command, the target shall not execute a write command or a read command.
I n parti cul ar, i t shal l not modi fy the value of the local array that would be modif ied by a wri te
command, or modi fy the val ue of the array poi nted to by the data pointer attri bute. The target may,
however, use the value of any attribute i n the generic payload, i ncl udi ng any extensions.
i) On receipt of an i gnore command, a component that usuall y acts as an interconnect component may
either f orward the transaction onward toward the target (that is, act as an i nterconnect), or may
return an error response (that is, act as a target). A component that routes read and wri te commands
dif ferently woul d be expected to return an error response.
j) A target is deemed to have executed an i gnore command successf ull y i f i t has recei ved the
transaction and has checked the values of the generic payload attributes to i ts own satisfaction (see
14.17).
k) The command attribute shall be set by the i nitiator, and shall not be overwritten by any i nterconnect
component or target.
l ) The default val ue of the command attri bute shall be TLM_I GNORE_COMMAND.
14.10 Address attribute
a) The method set_addr ess shall set the address attri bute to the value passed as an argument. The
method get_addr ess shall return the current value of the address attribute.
b) For a read command or a write command, the target shal l i nterpret the current val ue of the address
attri bute as the start address in the system memory map of the contiguous bl ock of data being read or
written. Thi s address may or may not correspond to the f irst byte i n the array poi nted to by the data
pointer attribute, dependi ng on the endianness of the host computer.
c) The address associated with any given byte in the data array i s dependent on the address attri bute,
the array i ndex, the streaming wi dth attribute, the endianness of the host computer, and the width of
the socket (see 14.18).
d) The val ue of the address attribute need not be word-ali gned (al though address calculations can be
considerably simpl if ied if the address attri bute i s a mul ti ple of the local socket wi dth expressed i n
bytes).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


479
Copyright 2012 IEEE. All rights reserved.
e) I f the target is unable to execute the transacti on with the given address attribute (because the address
is out-of-range, for exampl e), i t shall generate a standard error response. The recommended
response status is TLM_ADDRESS_ERROR_RESPONSE.
f ) The address attri bute shal l be set by the ini ti ator but may be overwri tten by one or more i nterconnect
components. This may be necessary if an i nterconnect component performs address transl ati on, for
exampl e, to translate an absol ute address in the system memory map to a rel ative address i n the
memory map known to the target. Once the address attribute has been overwri tten i n this way, the
old val ue i s l ost (unless it was expl icitly saved somewhere).
g) The default val ue of the address attribute shal l be 0.
14.11 Data pointer attribute
a) The method set_data_ptr shall set the data poi nter attri bute to the value passed as an argument. The
method get_data_ptr shall return the current val ue of the data poi nter attri bute. Note that the data
pointer attri bute is a poi nter to the data array, and these methods set or get the val ue of the pointer,
not the contents of the array.
b) For a read command or a wri te command, the target shal l copy data to or from the data array,
respecti vel y, honori ng the semantics of the remai ni ng attributes of the generic payload.
c) The ini ti ator is responsi ble f or all ocati ng storage f or the data and byte enable arrays. The storage
may represent the f inal source or destination of the data in the ini ti ator, such as a register f il e or
cache memory, or may represent a temporary buff er used to transfer data to and f rom the transacti on
level interface.
d) I n general , the organizati on of the generi c payload data array i s independent of the organizati on of
local storage withi n the i nitiator and the target. However, the generic payl oad has been designed so
that data can be copi ed to and from the target wi th a single call to memcpy in most circumstances.
This assumes that the target uses the same storage organization as the generi c payl oad. Thi s
assumpti on is made f or si mulati on eff iciency but does not restrict the expressi ve power of the
generic payl oad: the target is f ree to transform the data in any way i t wi shes as it copi es the data to
and f rom the data array.
e) For a read command or a write command, i t i s an error to call the transport interface wi th a
transaction obj ect having a null data pointer attribute.
f ) I n the case of TLM_IGNORE_COMMAND, the data pointer may poi nt to a data array or may be
null.
g) I f the data pointer i s not null , the length of the data array shall be greater than or equal to the val ue of
the data l ength attri bute, i n bytes.
h) The data poi nter attribute shal l be set by the initiator, and shall not be overwritten by any
interconnect component or target.
i) For a write command or TLM_I GNORE_COMMAND, the contents of the data array shall be set by
the ini ti ator, and shall not be overwritten by any interconnect component or target
j) For a read command, the contents of the data array may be overwritten by the target (honori ng the
semanti cs of the byte enabl e) but by no other component and only before the target sends a response.
A target sends a response in thi s sense whenever it returns control from the b_tr anspor t,
get_dir ect_mem_ptr, or transpor t_dbg methods, whenever i t passes the BEGI N_RESP phase as
an argument to nb_transport, or whenever it returns the value TLM_COMPLETED from
nb_transpor t.
k) The default val ue of the data poi nter attri bute shal l be 0, the nul l pointer.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


480
Copyright 2012 IEEE. All rights reserved.
14.12 Data length attribute
a) The method set_data_length shall set the data length attribute to the value passed as an argument.
The method get_data_length shal l return the current val ue of the data length attribute.
b) For a read command or a wri te command, the target shall interpret the data length attri bute as the
number of bytes to be copi ed to or f rom the data array, i ncl usive of any bytes disabl ed by the byte
enable attri bute.
c) The data length attri bute shal l be set by the ini ti ator, and shall not be overwri tten by any i nterconnect
component or target.
d) For a read command or a write command, the data length attribute shall not be set to 0. In order to
transf er zero bytes, the command attribute should be set to TLM_I GNORE_COMMAND.
e) I n the case of TLM_IGNORE_COMMAND, if the data poi nter is nul l, the val ue of the data l ength
attri bute i s undef ined.
f ) When using the standard socket classes of the i nteroperabil ity l ayer (or classes deri ved from these)
f or burst transf ers, the word l ength f or each transf er shal l be determi ned by the BUSWI DTH
templ ate parameter of the socket. BUSWI DTH is i ndependent of the data l ength attribute.
BUSWIDTH shall be expressed in bi ts. I f the data l ength is less than or equal to the BUSWI DTH /
8, the transaction is eff ectively model ing a si ngl e-word transfer, and i f greater, the transaction is
eff ectively modeling a burst. A single transaction can be passed through sockets of dif ferent bus
wi dths. The BUSWI DTH may be used to cal cul ate the l atency of the transf er.
g) The target may or may not support transactions with data l ength greater than the word l ength of the
target, whether the word l ength i s gi ven by the BUSWI DTH templ ate parameter or by some other
val ue.
h) If the target i s unable to execute the transaction wi th the gi ven data l ength, i t shal l generate a
standard error response, and it shall not modif y the contents of the data array. The recommended
response status i s TLM_BURST_ERROR_RESPONSE.
i ) The def ault value of the data l ength attri bute shal l be 0, whi ch is an i nvali d value unless the data
pointer i s nul l. Hence, unl ess the data poi nter is nul l, the data l ength attribute shall be set expli ci tl y
bef ore the transaction obj ect i s passed through an interface method cal l.
14.13 Byte enable pointer attribute
a) The method set_byte_enable_ptr shall set the pointer to the byte enable array to the val ue passed as
an argument. The method get_byte_enable_ptr shall return the current val ue of the byte enable
pointer attribute.
b) The el ements in the byte enable array shal l be i nterpreted as foll ows. A value of 0 shall i ndicate that
that corresponding byte i s disabl ed, and a value of 0xff shal l indicate that the correspondi ng byte is
enabled. The meaning of all other val ues shall be undef ined. The val ue 0xff has been chosen so that
the byte enable array can be used directly as a mask. The two macros TLM_BYTE_DISABLED and
TLM_BYTE_ENABLED are provided for convenience.
c) Byte enables may be used to create burst transf ers where the address increment between each beat is
greater than the number of si gni f icant bytes transferred on each beat, or to pl ace words in sel ected
byte lanes of a bus. At a more abstract l evel , byte enables may be used to create "l acy bursts" where
the data array of the generi c payload has an arbitrary pattern of hol es punched i n i t.
d) The byte enable mask may be defined by a small pattern appli ed repeatedl y or by a large pattern
covering the whol e data array (see 14.18).
e) The number of elements in the byte enable array shall be gi ven by the byte enable length attribute.
f ) The byte enable poi nter may be set to 0, the null pointer, in whi ch case byte enabl es shal l not be used
f or the current transaction, and the byte enabl e l ength shal l be ignored.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


481
Copyright 2012 IEEE. All rights reserved.
g) I f byte enabl es are used, the byte enabl e poi nter attri bute shall be set by the i nitiator, the storage f or
the byte enabl e array shall be al located by the ini tiator, the contents of the byte enabl e array shall be
set by the initiator, and nei ther the byte enabl e pointer nor the contents of the byte enable array shall
be overwritten by any i nterconnect component or target.
h) I f the byte enable pointer is non-nul l, the target shal l either impl ement the semanti cs of the byte
enable as def ined bel ow or shall generate a standard error response. The recommended response
status is TLM_BYTE_ENABLE_ERROR_RESPONSE.
i) I n the case of a write command, any i nterconnect component or target shoul d i gnore the val ues of
any disabl ed bytes i n the data array. It i s recommended that disabl ed bytes have no ef fect on the
behavior of any i nterconnect component or target. The i ni ti ator may set those bytes to any values
since they are goi ng to be ignored.
j) I n the case of a wri te command, when a target is doi ng a byte-by-byte copy f rom the transacti on data
array to a local array, the target shoul d not modif y the values of bytes in the local array
correspondi ng to disabled bytes in the generi c payl oad.
k) I n the case of a read command, any interconnect component or target should not modif y the values
of di sabled bytes i n the data array. The initiator can assume that di sabled bytes wi ll not be modi fi ed
by any interconnect component or target.
l ) I n the case of a read command, when a target is doing a byte-by-byte copy from a local array to the
transaction data array, the target shoul d ignore the val ues of bytes i n the local array correspondi ng to
disabl ed bytes i n the generic payl oad.
m) If the appl ication needs to vi olate these semanti cs for byte enabl es, or to viol ate any other semanti cs
of the generi c payload as def ined i n this document, the recommended approach woul d be to create a
new protocol trai ts class (see 14.2.2).
n) The default val ue of the byte enable poi nter attri bute shal l be 0, the null pointer.
14.14 Byte enable length attribute
a) The method set_byte_enable_length shall set the byte enable length attribute to the val ue passed as
an argument. The method get_byte_enable_length shall return the current value of the byte enable
length attribute.
b) For a read command or a wri te command, the target shal l interpret the byte enable length attri bute as
the number of el ements in the byte enable array.
c) The byte enabl e l ength attribute shall be set by the ini tiator, and shal l not be overwri tten by any
interconnect component or target.
d) The byte enable to be appl ied to a given element of the data array shall be cal cul ated usi ng the
f ormula byte_enable_arr ay_index = data_ar r ay_index % byte_enable_length. I n other words,
the byte enabl e array is appli ed repeatedly to the data array.
e) The byte enabl e length attribute may be greater than the data l ength attribute, i n which case any
superf luous byte enables should not af f ect the behavior of a read or write command, but could be
used by extensi ons.
f ) If the byte enabl e pointer i s 0, the nul l pointer, then the val ue of the byte enabl e l ength attribute shall
be i gnored by any interconnect component or target. If the byte enable poi nter i s non-0, the byte
enable length shall be non-0.
g) If the target i s unable to execute the transacti on with the given byte enable l ength, it shall generate a
standard error response. The recommended response status is
TLM_BYTE_ENABLE_ERROR_RESPONSE.
h) The default val ue of the byte enabl e length attribute shall be 0.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


482
Copyright 2012 IEEE. All rights reserved.
14.15 Streaming width attribute
a) The method set_streaming_width shall set the streami ng width attribute to the value passed as an
argument. The method get_streaming_width shal l return the current value of the streami ng width
attri bute.
b) For a read command or a wri te command, the target shal l interpret and act on the current value of the
streami ng wi dth attribute
c) Streami ng aff ects the way a component should i nterpret the data array. A stream consists of a
sequence of data transfers occurring on successive noti onal beats, each beat having the same start
address as given by the generi c payload address attri bute. The streaming wi dth attri bute shal l
determi ne the wi dth of the stream, that is, the number of bytes transf erred on each beat. I n other
words, streami ng aff ects the local address associated wi th each byte in the data array. In all other
respects, the organi zation of the data array is unaf fected by streami ng.
d) The bytes within the data array have a correspondi ng sequence of local addresses wi thin the
component accessi ng the generi c payl oad transaction. The lowest address i s gi ven by the value of
the address attri bute. The hi ghest address is given by the formula address_attr ibute +
str eaming_width 1. The address to or from which each byte i s being copied in the target shall be
set to the val ue of the address attribute at the start of each beat.
e) Wi th respect to the i nterpretati on of the data array, a si ngle transaction wi th a streaming wi dth shal l
be f uncti onal ly equivalent to a sequence of transactions each havi ng the same address as the origi nal
transaction, each havi ng a data length attribute equal to the streaming width of the origi nal , and each
wi th a data array that i s a di f ferent subset of the original data array on each beat. This subset
eff ectivel y steps down the ori ginal data array mai ntai ning the sequence of bytes.
f ) A streaming width of 0 shal l be i nval id. I f a streaming transf er i s not requi red, the streaming width
attri bute shoul d be set to a value greater than or equal to the value of the data l ength attri bute.
g) The val ue of the streaming wi dth attribute shall have no af f ect on the length of the data array or the
number of bytes stored i n the data array.
h) Wi dth conversion i ssues may arise when the streaming width is di ff erent from the wi dth of the
socket (when measured as a number of bytes) (see 14.18).
i) I f the target i s unabl e to execute the transaction with the given streaming width, i t shal l generate a
standard error response. The recommended response status is TLM_BURST_ERROR_RESPONSE.
j ) Streaming may be used i n conj uncti on wi th byte enables, in which case the streami ng width would
typi call y be equal to the byte enabl e length. It woul d also make sense to have the streami ng width a
multipl e of the byte enabl e l ength. Having the byte enabl e length a multiple of the streaming width
would impl y that dif ferent bytes were enabled on each beat.
k) The streaming wi dth attri bute shall be set by the ini ti ator, and shall not be overwri tten by any
interconnect component or target.
l ) The default val ue of the streami ng wi dth attribute shal l be 0.
14.16 DMI allowed attribute
a) The method set_dmi_allowed shall set the DMI al lowed attri bute to the val ue passed as an
argument. The method is_dmi_allowed shall return the current val ue of the DMI all owed attri bute.
b) The DMI all owed attri bute provi des a hi nt to an initiator that i t may try to obtai n a di rect memory
pointer. The target shoul d set this attri bute to true if the transacti on at hand coul d have been done
through DMI (see 11.2.9).
c) The default val ue of the DMI all owed attri bute shal l be false.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


483
Copyright 2012 IEEE. All rights reserved.
14.17 Response status attribute
a) The method set_response_status shal l set the response status attri bute to the value passed as an
argument. The method get_response_status shall return the current value of the response status
attri bute.
b) The method is_response_ok shall return true if and onl y if the current val ue of the response status
attri bute i s TLM_OK_RESPONSE. The method is_response_er ror shall return true if and onl y i f
the current value of the response status attri bute i s not equal to TLM_OK_RESPONSE.
c) The method get_response_str ing shall return the current value of the response status attri bute as a
text string.
d) As a general principl e, a target is recommended to support every f eature of the generic payl oad, but
in the case that it does not, i t shall generate the standard error response (see 14.17.1).
e) The response status attri bute shall be set to TLM_I NCOMPLETE_RESPONSE by the ini tiator, and
may or may not be overwri tten by the target. The response status attribute shall not be overwri tten
by an interconnect component. The value TLM_INCOMPLETE_RESPONSE shoul d be used to
indi cate that the component acti ng as the target did not attempt to execute the command, as might be
the case if the response was returned f rom a component that usuall y acts as an interconnect
component. But note that such a component woul d be al lowed to set the response status attribute to
any error response, because it is acting as a target.
f ) I f the target is abl e to execute the command successf ull y, i t shall set the response status attribute to
TLM_OK_RESPONSE. Otherwi se, the target may set the response status to any of the six error
responses li sted in Tabl e 56. The target should choose the appropriate error response depending on
the cause of the error.
g) I f a target detects an error but is unabl e to sel ect a speci fi c error response, i t may set the response
status to TLM_GENERI C_ERROR_RESPONSE.
h) The default val ue of the response status attri bute shall be TLM_INCOMPLETE_RESPONSE.
i) I n the case of TLM_I GNORE_COMMAND, a target that has received the transacti on and would
have been in a posi ti on to execute a read or write command shoul d return TLM_OK_RESPONSE.
Otherwise, the target may choose, at its di scretion, to set an error response usi ng the same cri teri a it
would have appl ied for a read or write command. For example, a target that does not support byte
enables woul d be permi tted (but not obli ged) to return
TLM_BYTE_ENABLE_ERROR_RESPONSE.
Table 56Error responses
Er ror r esponse I nter pr etation
TLM_I NCOMPLETE_RESPONSE Target di d not attempt to execute the command
TLM_ADDRESS_ERROR_RESPONSE Target was unabl e to act on the address attri bute, or address
out-of -range
TLM_COMMAND_ERROR_RESPONSE Target was unabl e to execute the command
TLM_BURST_ERROR_RESPONSE Target was unabl e to act on the data l ength or streami ng
wi dth
TLM_BYTE_ENABLE_ERROR_RESPONSE Target was unabl e to act on the byte enabl e
TLM_GENERI C_ERROR_RESPONSE Any other error
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


484
Copyright 2012 IEEE. All rights reserved.
j ) The presence of a generic payl oad extensi on or extended phase may cause a target to return a
dif ferent response status, provi ded that the rules concerning ignorable extensions are honored. I n
other words, wi thin the base protocol i t i s all owabl e that an extensi on may cause a command to f ail,
but it i s also al lowable that the target may ignore the extension and thus have the command succeed.
k) The target shal l be responsi ble for setting the response status attri bute at the appropriate poi nt i n the
li fetime of the transaction. In the case of the blocking transport i nterf ace, thi s means bef ore
returning control f rom b_tr anspor t. In the case of the non-blocking transport i nterf ace and the base
protocol, this means bef ore sending the BEGI N_RESP phase or returni ng a value of
TLM_COMPLETED.
l) It is recommended that the ini tiator shoul d al ways check the response status attri bute on recei vi ng a
transi tion to the BEGI N_RESP phase or after the completi on of the transacti on. An initiator may
choose to i gnore the response status if i t i s known i n advance that the value wi ll be
TLM_OK_RESPONSE, perhaps because it i s known i n advance that the ini ti ator i s onl y connected
to targets that always return TLM_OK_RESPONSE, but in general thi s wi ll not be the case. In other
words, the initiator ignores the response status at i ts own risk.
m) A target has some l ati tude when selecting an error response. For exampl e, if the command and
address attri butes are i n error, a target may be j ustif ied in setti ng any of
TLM_ADDRESS_ERROR_RESPONSE, TLM_COMMAND_ERROR_RESPONSE, or
TLM_GENERI C_ERROR_RESPONSE. When usi ng the response status to determine its behavi or
an initiator should not rely on the distinction between the si x categori es of error response al one,
although an i niti ator may use the response status to determi ne the content of di agnostic messages
pri nted f or the benefi t of the user.
14.17.1 The standard error response
When a target receives a generic payload transacti on, the target shoul d perf orm one and only one of the
f ol lowi ng actions:
a) Execute the command represented by the transacti on, honoring the semanti cs of the generic payload
attri butes, and honori ng the publi cly documented semantics of the component being modeled, and
set the response status to TLM_OK_RESPONSE.
b) Set the response status attribute of the generi c payl oad to one of the fi ve error responses as descri bed
above.
c) Generate a report using the standard SystemC report handl er with any of the four standard SystemC
severi ty level s i ndi cating that the command has f ai led or been i gnored, and set the response status to
TLM_OK_RESPONSE.
I t i s recommended that the target should perf orm exactly one of these acti ons, but an i mplementati on is not
obli ged or permi tted to enforce this recommendati on.
I t is recommended that a target f or a transacti on type other than the generic payl oad should f ol low thi s same
pri nci ple; that i s, execute the command as expected, or generate an error response using an attribute of the
transaction, or generate a SystemC report. However, the detail s of the semantics and the error response
mechanism f or such a transacti on are outside the scope of thi s standard.
The conditi ons f or satisf yi ng poi nt a) are determined by the expected behavior of the target component as
would be visible to a user of that component. The attri butes of the generic payl oad have defi ned semanti cs
that correspond to conventi onal usage i n the context of memory-mapped buses but that do not necessaril y
assume that the target behaves as a random-access memory. There are many subtl e corner cases. For
exampl e:
a) A target may have a memory-mapped register that supports both read and write commands, but the
write command is non-sticky; that is, write modif ies the state of the target, but a wri te foll owed by
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


485
Copyright 2012 IEEE. All rights reserved.
read wi ll not return the data j ust written but some other value determined by the state of the target. I f
thi s i s the normal expected behavior of the component, i t i s covered by point a).
b) A target may i mplement the write command to set a bi t whil e total ly ignoring the value of the data
attri bute. I f thi s i s the normal expected behavior of the target, it is covered by point a).
c) A read-onl y memory may ignore the write command wi thout si gnal ling an error to the i ni ti ator usi ng
the response status attribute. Si nce the wri te command is not changi ng the state of the target but i s
bei ng i gnored al together, the target should at l east generate a SystemC report with severi ty
SC_INFO or SC_WARNI NG.
d) A target should not under any circumstances i mplement the write command by perf ormi ng a read, or
vice versa. That woul d be a f undamental vi ol ation of the semantics of the generic payl oad.
e) A target may impl ement the read command accordi ng to the intent of the generic payload but wi th
addi ti onal side-ef fects. Thi s is covered by point a).
f ) A target with a set of memory-mapped registers forming an addressable register f il e receives a wri te
command with an out-of-range address. The target shoul d either set the response status attri bute of
the transaction to TLM_ADDRESS_ERROR_RESPONSE or generate a SystemC report.
g) A passive si mulati on bus monitor target recei ves a transaction with an address that i s outside the
physical range of the bus being modeled. The target may log the erroneous transaction for post-
processing under point a) and not generate an error response under points b) or c). Al ternati vel y, the
target may generate a report under point c).
I n other words, the disti nction between poi nts a), b), and c) is ultimately a pragmati c judgement to be made
on a case-by-case basis, but the defi niti ve rule for the generi c payload i s that a target should al ways perf orm
exactl y one of these actions.
Exampl e:
// Showing generic payload with command, addr ess, data, and response status
// The initiator
void thread() {
tlm::tlm_gener ic_payload trans; // Construct def ault generic payl oadsc_ti me del ay;
trans.set_command(tlm::TLM_WRI TE_COMMAND); // A wri te command
trans.set_data_length(4); // Write 4 bytes
trans.set_byte_enable_ptr (0); // Byte enables unused
trans.set_streaming_width(4); // Streami ng unused
f or (i nt i = 0; i < RUN_LENGTH; i += 4) { // Generate a series of transactions
int word = i;
trans.set_addr ess(i); // Set the address
trans.set_data_ptr ( (unsi gned char* )(&word) ); // Write data from local variable 'word'
trans.set_dmi_allowed(false); // Clear the DMI hint
trans.set_response_status( tlm::TLM_INCOMPLETE_RESPONSE );// Clear the response status
ini t_socket->b_tr anspor t(trans, delay);
if (trans.i s_response_error() ) // Check return value of b_transport
SC_REPORT_ERROR("TLM-2.0", trans.get_response_str ing().c_str());
...
}
...
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


486
Copyright 2012 IEEE. All rights reserved.
// The target
virtual void b_tr anspor t( tlm::tlm_generic_payl oad& trans, sc_core::sc_time& t)
{
tl m::tl m_command cmd = trans.get_command();
sc_dt::ui nt64 adr = trans.get_addr ess();
unsi gned char* ptr = trans.get_data_ptr ();
unsi gned int len = trans.get_data_length();
unsi gned char* byt = trans.get_byte_enable_ptr ();
unsi gned int wi d = trans.get_streaming_width();
if (adr+l en > m_l ength) { // Check f or storage address overfl ow
trans.set_response_status( tlm::TLM_ADDRESS_ERROR_RESPONSE );
return;
}
if (byt) { // Target unable to support byte enabl e attribute
trans.set_response_status( tlm::TLM_BYTE_ENABLE_ERROR_RESPONSE );
return;
}
if (wi d < len) { // Target unable to support streaming width attri bute
trans.set_response_status( tlm::TLM_BURST_ERROR_RESPONSE );
return;
}
if (cmd == tl m::TLM_WRITE_COMMAND) // Execute command
memcpy(&m_storage[ adr], ptr, l en);
else i f (cmd == tlm::TLM_READ_COMMAND)
memcpy(ptr, & m_storage[ adr], l en);
trans.set_response_status( tlm::TLM_OK_RESPONSE ); // Successf ul compl etion
}
// Showing generic payload with byte enables
// The initiator
void thread() {
tl m::tlm_generic_payload trans;
sc_time del ay;
stati c word_t byte_enabl e_mask = 0x0000f ff ful; // MSB..LSB regardless of host-endianness
trans.set_command(tlm::TLM_WRITE_COMMAND);
trans.set_data_length(4);
trans.set_byte_enable_ptr ( reinterpret_cast<unsigned char* >( &byte_enable_mask ) );
trans.set_byte_enable_length(4);
trans.set_streaming_width(4);
...
...
// The target
virtual void b_transport(
tl m::tlm_generic_payload& trans, sc_core::sc_time& t)
{
tl m::tlm_command cmd = trans.get_command();
sc_dt::ui nt64 adr = trans.get_address();
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


487
Copyright 2012 IEEE. All rights reserved.
unsi gned char* ptr = trans.get_data_ptr();
unsi gned int len = trans.get_data_length();
unsi gned char* byt = trans.get_byte_enable_ptr();
unsi gned int bel = trans.get_byte_enable_length();
unsi gned int wi d = trans.get_streaming_width();
if (cmd == tl m::TLM_WRITE_COMMAND) {
if (byt) {
f or (unsigned i nt i = 0; i < l en; i++) // Byte enable appli ed repeatedly up data array
if ( byt[ i % bel ] == TLM_BYTE_ENABLED )
m_storage[adr+i ] = ptr[i ]; // Byte enabl e [i ] corresponds to data ptr [i ]
}
else
memcpy(&m_storage[ adr] , ptr, l en); // No byte enabl es
} else if (cmd == tl m::TLM_READ_COMMAND) {
if (byt) { // Target does not support read with byte enabl es
trans.set_response_status( tlm::TLM_BYTE_ENABLE_ERROR_RESPONSE );
return;
}
else
memcpy(ptr, & m_storage[ adr], l en);
}
trans.set_response_status( tl m::TLM_OK_RESPONSE );
}
14.18 Endianness
14.18.1 Introduction
When usi ng the generi c payload to transfer data between ini ti ator and target, both the endi anness of the host
machi ne (host endianness) and the endi anness of the initiator and target being model ed (modeled
endi anness) are rel evant. This clause defi nes rules to ensure i nteroperabili ty between ini ti ators and targets
usi ng the generic payl oad, so i s speci fi call y concerned wi th the organizati on of the generic payl oad data
array and byte enable array. However, the rules given here may have an i mpact on some of the choi ces made
in modeli ng endi anness beyond the i mmediate scope of the generic payl oad.
A general pri nci pl e i n the TLM-2.0 approach to endi anness is that the organizati on of the generic payl oad
data array depends onl y on i nformation known l ocall y withi n each i nitiator, interconnect component, or
target. In particular, i t depends on the width of the l ocal socket through which the transaction is sent or
received, the endi anness of the host computer, and the endianness of the component being model ed.
The organi zation of the generi c payload and the approach to endianness has been chosen to maximize
simul ation eff ici ency i n certain common system scenarios, parti cul arl y mi xed-endian systems. The rules
given bel ow di ctate the organi zation of the generi c payload, and this i s i ndependent of the organizati on of
the system bei ng model ed. For example, a word within the generic payl oad need not necessari ly
correspond in i nternal representation with any word within the modeled architecture.
At a macroscopic l evel , the mai n pri nci pl e i s that the generi c payload assumes components in a mixed-
endi an system to be wired up MSB to MSB (most-signif icant byte) and LSB to LSB (l east-si gni fi cant byte).
I n other words, i f a word is transf erred between components of dif feri ng endianness, the MSB ... LSB
rel ationshi p is preserved, but the l ocal address of each byte as seen wi thi n each component will necessari ly
change using the transformation general ly cal led addr ess swi zzl i ng. This is true wi thin both the modeled
system and the TLM-2.0 model . On the other hand, if a mi xed-endian system i s wi red such that the l ocal
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


488
Copyright 2012 IEEE. All rights reserved.
addresses are i nvariant withi n each component (that i s, each byte has the same l ocal address when seen from
any component), then an expl icit byte swap woul d need to be i nserted i n the TLM-2.0 model.
I n order to achieve interoperabil ity with respect to the endianness of the generic payl oad arrays, i t is onl y
necessary to obey the rul es gi ven in thi s clause. A set of hel per functi ons i s provided to assi st wi th the
organization of the data array (see 14.20).
14.18.2 Rules
a) I n the foll owing rules, the generic payload data array is denoted as data and the generic payl oad
byte enable array as be.
b) When usi ng the standard socket cl asses of the i nteroperabi li ty l ayer (or classes derived from these),
the contents of the data and byte enabl e arrays shal l be interpreted usi ng the BUSWI DTH template
parameter of the socket through whi ch the transaction is sent or received l ocall y. The ef fective word
length shall be cal cul ated as (BUSWIDTH + 7)/8 bytes and i n the f ollowi ng rules i s denoted as W.
c) This quantity W def ines the l ength of a word withi n the data array, each word being the amount of
data that could be transf erred through the l ocal socket on a si ngl e beat. The data array may contai n a
single word, a part-word, or several contiguous words or part-words. Only the first and last words i n
the data array may be part-words. Thi s description ref ers to the internal organization of the generi c
payl oad, not to the organi zation of the archi tecture being model ed.
d) I f a given generic payload transaction obj ect i s passed through sockets of di ff erent widths, the data
array word l ength would appear di f ferent when cal cul ated f rom the point of view of dif ferent
sockets (see the descri ption of wi dth conversi on below).
e) The order of the bytes within each word of the data array shall be host-endian. That i s, on a littl e-
endi an host processor, wi thin any given word data[n] shall be less si gni fi cant than data[n+1], and
on a big-endian host processor, data[n] shal l be the more si gni fi cant than data[n+1].
f ) The word boundari es in the data array shal l be address-al igned; that is, they shall fall on addresses
that are i nteger mul ti pl es of the word length W. However, neither the address attri bute nor the data
length attri bute are requi red to be mul ti pl es of the word l ength. Hence the possibil ity that the fi rst
and l ast words i n the data array could be part-words.
g) The order of the words within the data array shall be determi ned by thei r addresses in the memory
map of the model ed system. For array i ndex values l ess than the val ue of the streami ng width
attri bute, the l ocal addresses of successi ve words shal l be in increasi ng order, and (excl udi ng any
leading part-word) shall equal address_attribute (addr ess_attr ibute % W ) + NW, where N i s a
non-negati ve i nteger, and % indicates remainder on di vi si on.
h) I n other words, using the notati on { a,b,c,d} to li st the el ements of the data array in i ncreasing order
of array index, and usi ng LSBN to denote the least si gni fi cant byte of the Nth word, on a li ttl e-
endi an host bytes are stored i n the order { ..., MSB0, LSB1, ..., MSB1, LSB2, ...} , and on a big-endian
host { ... LSB
0
, MSB
1
, ... LSB
1
, MSB
2
, ...} , where the number of bytes in each ful l word i s given by
W, and the total number of bytes is given by the data_length attribute.
i) The above rules ef fecti vel y mean that initiators and targets are connected LSB-to-LSB, MSB-to-
MSB. The rul es have been chosen to give optimal si mulati on speed in the case where the maj ori ty of
ini ti ators and targets are model ed usi ng host endianness whatever thei r native endianness, also
known as arithmetic mode.
j ) I t i s strongl y recommended that appli cati ons shoul d be i ndependent of host endianness, that is,
should model the same behavi or when run on a host of either endi anness. Thi s may require the use
of helper f uncti ons or condi tional compil ation.
k) I f an initiator or target i s modeled usi ng i ts native endi anness and that is dif ferent f rom host
endi anness, i t wil l be necessary to swap the order of bytes withi n a word when transf erring data to or
f rom the generi c payload data array. Helper f uncti ons are provi ded f or thi s purpose.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


489
Copyright 2012 IEEE. All rights reserved.
l) For exampl e, consi der the f oll owing SystemC code f ragment, whi ch uses the li teral value
0xAABBCCDD to i nitiali ze the generi c payload data array:
int data = 0xAABBCCDD;
trans.set_data_ptr( rei nterpret_cast<unsigned char* >( &data ) );
trans.set_data_length(4);
trans.set_address(0);
socket->b_transport(trans, delay);
m) The C++ compil er wil l interpret the li teral 0xAABBCCDD in host-endian form. I n ei ther case, the
MSB has value 0xAA and the LSB has val ue 0xDD. Assuming thi s is the i ntent, the code fragment
is val id and i s independent of host endi anness. However, the array index of the four bytes wi ll di ff er
depending on host endianness. On a l ittl e-endi an host, data[ 0] = 0xDD, and on a big-endian host,
data[0] = 0xAA. The correspondence between local addresses in the modeled system and array
indexes wil l dif fer dependi ng whether modeled endianness and host endianness are equal:
Littl e-endi an model and l ittle-endian host: data[0] is 0xDD and local address 0
Big-endi an model and li ttle-endian host: data[0] is 0xDD and local address 3
Littl e-endi an model and big-endian host: data[ 0] is 0xAA and l ocal address 3
Big-endi an model and big-endian host: data[0] i s 0xAA and l ocal address 0
n) Code such as the fragment shown above would not be portable to a host computer that uses neither
li ttle nor bi g endi anness. In such a case, the code would have to be re-wri tten to access the generi c
payl oad data array using byte addressi ng only.
o) When a l ittle-endian and a bi g-endian model i nterpret a given generic payload transacti on, then by
def ini ti on they wil l agree on whi ch is the MSB and LSB of a word, but they wi ll each use dif ferent
local addresses to access the bytes of the word.
p) Neither the data length attribute nor the address attri bute are requi red to be i nteger mul ti pl es of W.
However, having address and data l ength ali gned wi th word boundaries and havi ng W be a power of
2 considerably si mplif ies access to the data array. Just to emphasi ze the poi nt, i t would be perf ectl y
in order for a generi c payload transacti on to have an address and data length that i ndicated three
bytes in the middle of a 48-bit socket. If a particular target is unable to support a given address
attri bute or data length, it should generate a standard error response (see 14.17).
q) For example, on a li ttl e-endi an host and with W = 4, address = 1, and data_length = 4, the fi rst
word would contain three bytes at addresses 1...3, and the second word 1 byte at address 4.
r) Single byte and part-word transf ers may be expressed usi ng non-ali gned addressing. For example,
given W = 8, address = 5, and data = { 1,2} , the two bytes wi th l ocal addresses 5 and 6 are accessed
in an order dependent on endianness.
s) Part-word and non-ali gned transf ers can al ways be expressed usi ng integer multi ples of W together
wi th byte enabl es. This impl ies that a gi ven transaction may have several equall y vali d generic
payl oad representations. For example, gi ven a li ttle-endian host and a li ttle-endian initiator:
address = 2, W = 4, data = { 1} i s equival ent to
address = 0, W = 4, data = { x, x, 1, x} , and be = { 0, 0, 0xff , 0}
address = 2, W = 4, data = { 1,2,3,4} i s equivalent to
address = 0, W = 4, data = { x, x, 1, 2, 3, 4, x, x} , and be = { 0, 0, 0xff , 0xf f , 0xf f, 0xff , 0, 0} .
t) For part-word access, the necessity to use byte enabl es is dependent on endianness. For example,
given the intent to access the whole of the f irst word and the LSB of the second word, given a l ittl e-
endi an host this mi ght be expressed as
address = 0, W = 4, data = { 1,2,3,4,5}
Gi ven a bi g-endi an host, the equivalent would be
address = 0, W = 4, data = { 4,3,2,1,x,x,x,5} , be = { 0xff , 0xf f, 0xff , 0xff , 0, 0, 0, 0xff } .
u) When two sockets are bound together, they necessaril y have the same BUSWIDTH. However, a
transaction may be f orwarded f rom a target socket to an i niti ator socket of a dif ferent bus width. In
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


490
Copyright 2012 IEEE. All rights reserved.
thi s case, wi dth conversi on of the generi c payl oad transaction must be considered (Figure 27). Any
wi dth conversi on has i ts own i ntrinsic endianness, depending on whether the least- or most-
signif icant byte of the wider socket is picked out fi rst.
Figure 27Width conversion
v) When the endi anness chosen f or a width conversi on matches the host endianness, the width
conversion is effecti vel y f ree, meaning that a single transaction obj ect can be f orwarded from
socket-to-socket wi thout modif ication. Otherwi se, two separate generic payload transaction obj ects
would be required. In Fi gure 27, the width conversion between the 4-byte socket and the 2-byte
socket uses host-endi anness, movi ng the l ess-signif i cant bytes to lower addresses whi le retaini ng the
host-endi an byte order wi thin each word. The i nitiator and target both access the same sequence of
bytes i n the data array, but their l ocal addressi ng schemes are quite di fferent.
w) I f a wi dth conversion is perf ormed f rom a narrower socket to a wider socket, the choice has to be
made as to whether or not to perf orm address ali gnment on the outgoi ng transacti on. Perf ormi ng
address al ignment wil l always necessi tate the constructi on of a new generi c payl oad transaction
object.
x) Simil ar wi dth conversi on issues arise when the streaming wi dth attri bute is non-zero but diff erent
f rom W. A choi ce has to be made as to the order in whi ch to read off the bytes down the data array
depending on host endianness and the desired endi anness of the wi dth conversi on.
14.19 Helper functions to determine host endianness
14.19.1 Introduction
A set of helper functi ons i s provided to determine the endianness of the host computer. These are i ntended
f or use when creati ng or i nterpreting the generic payl oad data array.
14.19.2 Definition
namespace tl m {
enum tlm_endianness {
W = 4
bytes
W = 2
bytes Bi g-endian
Little-endian Interconnect
component Initiator Target
LSB
MSB
LSB
MSB
3
2
1
0
7
6
5
4
LSB
MSB
0
1
2
3
4
5
6
7
Local
address
Local
address
Word
Word
Word
Word
Word
Word
Generi c
payload
data array
Generi c
payload
data array
Little-endian
width
conversion
Little-endian host
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


491
Copyright 2012 IEEE. All rights reserved.
TLM_UNKNOWN_ENDI AN, TLM_LI TTLE_ENDIAN, TLM_BI G_ENDI AN } ;
inl ine tl m_endianness get_host_endianness(voi d);
inl ine bool host_has_little_endianness(voi d);
inl ine bool has_host_endianness(tlm_endianness endianness);
} // namespace tl m
14.19.3 Rules
a) The f unction get_host_endianness shall return the endianness of the host.
b) The f uncti on host_has_little_endianness shall return the val ue true i f and only if the host i s l ittl e-
endi an.
c) The functi on has_host_endianness shall return the value true i f and only if the endianness of the
host is the same as that indicated by the argument.
d) I f the host is nei ther l ittle- nor bi g-endi an, the val ue returned from the above three functi ons shall be
undef ined.
14.20 Helper functions for endianness conversion
14.20.1 Introduction
The rules governi ng the organization of the generi c payload data array are wel l-defi ned, and in many simpl e
cases, writing host-independent C++ code to create and interpret the data array is a straightf orward task.
However, the rules do depend on the relationshi p between the endi anness of the model ed component and
host endi anness, so creati ng host-independent code can become qui te complex in cases i nvol vi ng non-
ali gned addressing and data word widths that dif fer f rom the socket wi dth. A set of helper functi ons is
provided to assist wi th this task.
Wi th respect to endi anness, i nteroperabi li ty depends onl y on the endi anness rules being foll owed. Use of the
hel per functi ons is not necessary for i nteroperabili ty.
The moti vation behi nd the endianness conversion functi ons i s to permi t the C++ code that creates a generic
payl oad transaction for an initiator to be written once with l ittle regard for host endi anness, and then to have
the transaction converted to match host endianness with a singl e f uncti on call . Each conversion f uncti on
takes an existi ng generi c payload transaction and modif ies that transaction i n-place. The conversi on
f uncti ons are organi zed in pai rs, a to_hostendi an functi on and a from_hostendi an functi on, which should
always be used together. The to_hostendi an f unction should be call ed by an i ni ti ator bef ore sending a
transaction through a transport interf ace, and fr om_hostendi an on recei vi ng back the response.
Four pairs of functions are provided, the _generi c pair bei ng the most general and powerful, and the _word,
_al i gned and _si ngl e f uncti ons being variants that can only handl e restri cted cases. The transformation
perf ormed by the _generi c functi ons is relati vel y computati onall y expensi ve, so the other f uncti ons should
be pref erred f or eff iciency wherever possi ble.
The conversion functi ons provide suf f icient f lexibi li ty to handle many common cases, i ncl udi ng both
ari thmeti c mode and byte or der mode. Ar i thmeti c mode is where a component stores data words i n host-
endi an format f or eff iciency when performing arithmetic operati ons, regardless of the endi anness of the
component being model ed. Byte order mode i s where a component stores bytes i n an array i n ascending
address order, di sregardi ng host endianness. The use of arithmetic mode is recommended f or simul ati on
speed. Byte order mode may necessitate byte swapping when copying data to and f rom the generi c payload
data array.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


492
Copyright 2012 IEEE. All rights reserved.
The conversion f unctions use the concept of a data word. The data word i s independent of both the TLM-2.0
socket wi dth and the word width of the generic payl oad data array. The data word is i ntended to represent a
register that stores bytes in host-endi an order within the component model (regardless of the endianness of
the component being model ed). If the data word wi dth is dif ferent to the socket wi dth, the hostendi an
f uncti ons may have to perf orm an endianness conversi on. If the data word is just one byte wi de, the
hostendi an functi ons wil l eff ectively perform a conversi on f rom and to byte or der mode.
I n summary, the approach to be taken wi th the hostendi an conversion f uncti ons is to write the initiator code
as i f the endianness of the host computer matched the endianness of the component bei ng modeled, whil e
keeping the bytes wi thin each data word in actual host-endian order. For data words wider than the host
machi ne word length, use an array in host-endian order. Then i f host endi anness dif fers f rom modeled
endi anness, si mply cal l the hostendi an conversion functions.
14.20.2 Definition
namespace tl m {
templ ate<cl ass DATAWORD>
inl ine voi d tlm_to_hostendian_gener ic(tlm_generic_payl oad * , unsigned int );
templ ate<cl ass DATAWORD>
inl ine voi d tlm_from_hostendian_gener ic(tlm_generic_payl oad * , unsigned int );
templ ate<cl ass DATAWORD>
inl ine voi d tlm_to_hostendian_wor d(tlm_generic_payl oad * , unsigned i nt);
templ ate<cl ass DATAWORD>
inl ine voi d tlm_from_hostendian_wor d(tlm_generic_payl oad * , unsigned i nt);
templ ate<cl ass DATAWORD>
inl ine voi d tlm_to_hostendian_aligned(tlm_generic_payl oad * , unsi gned int);
templ ate<cl ass DATAWORD>
inl ine voi d tlm_from_hostendian_aligned(tlm_generic_payl oad * , unsigned i nt);
templ ate<cl ass DATAWORD>
inl ine voi d tlm_to_hostendian_single(tlm_generic_payl oad * , unsi gned i nt);
templ ate<cl ass DATAWORD>
inl ine voi d tlm_from_hostendian_single(tlm_generic_payl oad * , unsigned i nt);
inl ine voi d tlm_from_hostendian(tlm_generic_payl oad * );
} // namespace tl m
14.20.3 Rules
a) The fi rst argument to a function of the f orm to_hostendi an shoul d be a poi nter to a generic payl oad
transaction object that would be vali d i f it were sent through a transport i nterface. The function
should only be cal led after constructing and i niti ali zing the transaction obj ect and before passing i t
to an interf ace method call .
b) The f irst argument to a functi on of the f orm from_hostendi an shall be a pointer to a generic payl oad
transaction object previ ousl y passed to to_hostendi an. The functi on should only be call ed when the
ini ti ator recei ves a response for the gi ven transaction or the transaction is complete. Since the
f uncti on may modif y the transacti on and i ts arrays, i t should only be call ed at the end of the l if etime
of the transacti on object.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


493
Copyright 2012 IEEE. All rights reserved.
c) I f a to_hostendi an function i s cal led f or a gi ven transaction, the correspondi ng fr om_hostendi an
f uncti on shoul d al so be call ed wi th the same template and function arguments. Alternativel y, the
f uncti on tlm_from_hostendian(tlm_generic_payl oad * ) can be cal led f or the given transacti on.
This functi on uses addi ti onal context i nf ormation stored wi th the transacti on obj ect (as an ignorable
extension) to recover the template and function argument val ues, but is marginall y slower in
executi on.
d) The second argument to a hostendi an function should be the wi dth of the local socket through whi ch
the transaction is passed, expressed i n bytes. Thi s i s equi val ent to the word l ength of the generic
payl oad data array with respect to the local socket. Thi s shal l be a power of 2.
e) The templ ate argument to a hostendi an function should be a type representing the i nternal i ni ti ator
data word f or the endianness conversi on. The expressi on sizeof (DATAWORD) i s used to determine
the width of the data word i n bytes, and the assi gnment operator of type DATAWORD i s used
duri ng copyi ng. sizeof (DATAWORD) shal l be a power of 2.
f ) The i mplementation of to_hostendi an adds an extension to the generic payload transaction obj ect to
store context inf ormati on. This means that to_hostendi an can only be call ed once bef ore cal li ng
fr om_hostendi an.
g) The fol lowing constraints are common to every pair of hostendi an f unctions. The term i nteger
mul ti pl e means 1 x , 2 x , 3 x , ... and so f orth:
Socket wi dth shall be a power of 2
Data word wi dth shall be a power of 2
The streami ng width attri bute shal l be an integer mul ti pl e of the data word wi dth
The data length attribute shall be an i nteger multipl e of the streami ng wi dth attribute
h) The hostendi an_generi c functions are not subject to any f urther specif ic constraints. In particular,
they support byte enabl es, streaming, and non-al igned addresses and word widths.
i ) The remai ni ng pai rs of f uncti ons, namely hostendi an_word, hostendi an_al i gned, and
hostendi an_si ngl e, all share the f ol lowi ng additional constrai nts:
Data word width shal l be no greater than socket wi dth, and as a consequence, socket width
shal l be a power-of -2 multipl e of data word width.
The streaming width attribute shal l equal the data l ength attribute. That i s, streaming i s not
supported.
Byte enable granul arity shal l be no fi ner than data word wi dth. That is, the bytes in a given data
word shal l be ei ther all enabl ed or al l disabl ed.
I f byte enables are present, the byte enable length attribute shall equal the data length attribute.
j) The hostendi an_al i gned functi ons al one are subj ect to the f oll owing additional constrai nts:
The address attribute shal l be an integer mul tipl e of the socket wi dth.
The data length attribute shall be an i nteger multipl e of the socket wi dth.
k) The hostendi an_si ngl e functions al one are subject to the f ollowi ng additional constrai nts:
The data length attribute shall equal the data word width.
The data array shall not cross a data word boundary and, as a consequence, shall not cross a
socket boundary.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


494
Copyright 2012 IEEE. All rights reserved.
14.21 Generic payload extensions
14.21.1 Introduction
Theextensi on mechanismi san i ntegral part of thegeneric payload, and isnot intendedto beused separatel y
fromthegeneric payload. Its purposei s to permi t attributesto beadded to thegeneric payload. Extensi ons
can bei gnorabl eor non-ignorabl e, mandatory or non-mandatory.
14.21.1.1 Ignorable extensions
Being i gnorabl e meansthat any component other than thecomponent that added theextension is permi tted
to behave as i f the extensi on were absent. As a consequence, the component that added the i gnorabl e
extension cannot rely on any other component reacting in any way to thepresence of the extension, and a
component recei vi ng an ignorable extension cannot rely on other components having recognized that
extension. This definition appl iestogeneric payload extensi onsandtoextended phasesali ke.
A component shall not fai l and shall not generatean error responsebecause of theabsenceof an i gnorabl e
extensi on. In this sense, i gnorabl eextensions arealso non-mandatory extensions. A component may fai l or
generate an error response because of the presence of an i gnorabl e extensi on but also has the choi ce of
ignori ngtheextensi on.
Ingeneral, an ignorabl eextensi on can bethought of asonefor whi chthereexists an obviousand safedefaul t
val ue such that any interconnect component or target can behave normal ly i n the absence of the gi ven
extensi on by assuming the default value. An example mi ght be the privi lege level associated wi th a
transaction, wherethedefault is thel owest level .
Ignorable extensions may be used to transport auxi liary, si de-band, or simul ation-related informati on or
meta-data. For exampl e, auni quetransacti oni dentifier, thewall -timewhenthetransaction wascreated, or a
diagnosti c fil ename.
Ignorableextensions arepermittedby thebaseprotocol .
14.21.1.2 Non-ignorable and mandatory extensions
A non-ignorable extension is an extensi on that every component receiving the transaction isobli ged to act
on if present. A mandatory extensi on is an extension that i s requi red to be present. Non-i gnorable and
mandatory extensi onsmay be used when speci ali zi ng thegeneric payload to model thedetail s of aspecific
protocol. Non-i gnorabl eandmandatory extensi ons requirethedefi nition of anew protocol traitscl ass.
14.21.2 Rationale
The rationale behind the extension mechani sm i s twofold. Fi rst, to permi t TLM-2.0 sockets that carry
variations on the core attri bute set of the generi c payload to be speci ali zed with the same protocol trai ts
class, thus al lowi ng themto be bound together directly wi th no need for adaption or bri dgi ng. Second, to
permi t easy adapti on between di fferent protocols where both are based on the same generi c payload and
extensi on mechanism. Without the extension mechani sm, the addi ti on of any new attri bute to the generic
payl oad would requi re the definition of a new transaction class, l eading to the need for multipl e adapters.
The extension mechanism al lows variations to be introduced into the generi c payl oad, thus reduci ng the
amount of coding work that needs to bedonetotraversesocketsthat carry different protocol s.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


495
Copyright 2012 IEEE. All rights reserved.
14.21.3 Extension pointers, objects and transaction bridges
An extension i s an object of a type deri ved f rom the cl ass tlm_extension. The generic payl oad contains an
array of poi nters to extensi on obj ects. Every generi c payl oad obj ect i s capabl e of carrying a si ngl e instance
of every type of extensi on.
The array-of -poi nters to extensi ons has a slot for every regi stered extensi on. The set_extension method
simpl y overwrites a pointer and, in principl e, can be cal led from an ini ti ator, interconnect component, or
target. This provides a very a fl exi ble l ow-l evel mechani sm, but it is open to mi suse. The ownershi p and
del etion of extensi on objects has to be well understood and careful ly considered by the user.
When creating a transaction bri dge between two separate generic payl oad transactions, i t is the
responsibi lity of the bri dge to copy any extensions, i f required, f rom the incomi ng transaction obj ect to the
outgoing transaction object, and to own and manage the outgoing transaction and its extensi ons. The same
holds f or the data array and byte enabl e array. The methods deep_copy_from and update_or iginal_from
are provi ded so that a transaction bri dge can perform a deep copy of a transaction object, including the data
and byte enabl e arrays and the extensi on obj ects. I f the bridge adds f urther extensions to the outgoi ng
transaction, those extensions woul d be owned by the bri dge.
The management of extensi ons i s descri bed more ful ly in 14.5.
14.21.4 Rules
a) An extensi on can be added by an ini ti ator, interconnect, or target component. In particular, the
creation of extensi ons is not restricted to initiators.
b) Any number of extensions may be added to each instance of the generic payload.
c) I n the case of an ignorable extension, any component (excepti ng the component that added the
extensi on) i s all owed to ignore the extensi on, and ignorable extensi ons are not mandatory
extensi ons. Having a component fail because of either the absence of an ignorable extensi on or the
absence of a response to an ignorabl e extensi on woul d destroy interoperabi li ty.
d) There i s no bui lt-i n mechani sm to enforce the presence of a gi ven extensi on, nor is there a
mechanism to ensure that an extensi on i s i gnorable.
e) The semantics of each extension shall be appl ication-def ined. There are no pre-def ined extensi ons.
f ) An extension shal l be created by derivi ng a user-def ined class f rom the cl ass tlm_extension, passi ng
the name of the user-defi ned cl ass i tsel f as a templ ate argument to tlm_extension, then creating an
object of that class. The user-defi ned extensi on class may include members that represent extended
attri butes of the generi c payload.
g) The virtual method free of the class tlm_extension_base shall delete the extensi on object. Thi s
method may be overridden to i mplement user-def ined memory management of extension, but this is
not necessary.
h) The pure vi rtual functi on clone of class tlm_extension shall be def i ned i n the user-def ined
extensi on cl ass to cl one the extensi on obj ect, i ncl udi ng any extended attributes. This clone method
is i ntended f or use in conjuncti on with generi c payl oad memory management. I t shall create a copy
of any extensi on obj ect such that the copy can survive the destructi on of the origi nal object wi th no
visibl e side-ef fects.
i ) The pure virtual f uncti on copy_from of class tlm_extension shall be defi ned in the user-defi ned
extensi on class to modif y the current extension obj ect by copying the attri butes of another extension
object.
j) The act of instantiating the class template tlm_extension shall cause the publ ic data member I D to
be ini ti al ized, and thi s shall have the ef fect of registering the given extension wi th the generi c
payl oad object and assigning a unique ID to the extensi on. The I D shal l be unique across the whole
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


496
Copyright 2012 IEEE. All rights reserved.
executi ng program. That is, each instantiation of the class template tlm_extension shal l have a
disti nct I D, whereas all extensi on objects of a given type shall share the same I D.
k) The generi c payl oad shall behave as if i t stored pointers to the extensions in a re-si zable array, where
the I D of the extensi on gi ves the index of the extension pointer in the array. Registeri ng the
extensi on with the generic payload shal l reserve an array index f or that extension. Each generic
payl oad object shal l contain an array capable of storing pointers to every extension registered i n the
currently executing program.
l ) The pointers i n the extensi on array shall be nul l when the transacti on i s constructed.
m) Each generic payload obj ect can store a poi nter to at most one obj ect of any given extension type
(but to many obj ects of di ff erent extensions types). (There exi sts a uti li ty class
instance_specific_extension, which enables a generi c payload object to reference several extensi on
objects of the same type (see 16.4).)
n) The function max_num_extensions shal l return the number of extension types, that is, the size of
the extension array. As a consequence, the extensi on types shall be numbered f rom 0 to
max_num_extensions()-1.
o) The methods set_extension, set_auto_extension, get_extension, clear_extension, and
release_extension are provided in several f orms, each of whi ch i denti fy the extensi on to be
accessed in dif ferent ways: usi ng a function templ ate, usi ng an extension poi nter argument, or using
an I D argument. The functi ons wi th an I D argument are i ntended f or speci ali st programming tasks
such as when cloning a generi c payl oad object, and not for general use i n appli cati ons.
p) The method set_extension(T* ) shall replace the pointer to the extensi on obj ect of type T in the
array-of-poi nters with the val ue of the argument. The argument shall be a pointer to a registered
extensi on. The return value of the f uncti on shal l be the previ ous val ue of the pointer in the generic
payl oad that was repl aced by this cal l, which may be a null pointer. The method
set_auto_extension(T* ) shall behave si mil arly, except that the extensi on shal l be marked f or
automati c deleti on.
q) The method set_extension(unsigned int, tlm_extension_base* ) shal l repl ace the pointer to the
extensi on obj ect i n the array-of -pointers at the array index given by the fi rst argument wi th the value
of the second argument. The given i ndex shall have been regi stered as an extension ID; otherwi se,
the behavi or of the f unction i s undefi ned. The return value of the f unction shal l be the previ ous val ue
of the poi nter at the given array index, whi ch may be a null pointer. The method
set_auto_extension(unsigned int, tlm_extension_base* ) shal l behave simi larly, except that the
extension shal l be marked for automatic del etion
r) I n the presence of a memory manager, a call to set_auto_extension f or a gi ven extensi on is
equi val ent to a call to set_extension immediatedly fol lowed by a call to release_extension for that
same extension. In the absence of a memory manager, a cal l to set_auto_extension wil l cause a run-
ti me error.
s) I f an extensi on i s marked for automatic del etion, the given extensi on object should be deleted or
pool ed by the impl ementation of the method free of a user-defi ned memory manager. Method free
is call ed by method release of class tlm_gener ic_payload when the ref erence count of the
transaction obj ect reaches 0. The extensi on object may be deleted by call ing method reset of class
tlm_gener ic_payload or by call ing method free of the extension object itself .
t) I f the generic payload object already contained a non-nul l poi nter to an extensi on of the type bei ng
set, then the old pointer i s overwritten.
u) The method functions get_extension(T* & ) and T* get_extension() shall each return a pointer to
the extensi on object of the given type, i f i t exists, or a null poi nter i f it does not exi st. The type T
shal l be a poi nter to an obj ect of a type derived f rom tlm_extension. I t is not an error to attempt to
retri eve a non-existent extension using thi s f unction template.
v) The method get_extension(unsigned int) shall return a poi nter to the extension obj ect wi th the ID
given by the argument. The gi ven index shall have been registered as an extensi on ID; otherwise, the
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


497
Copyright 2012 IEEE. All rights reserved.
behavior of the f uncti on i s undef ined. I f the poi nter at the gi ven index does not poi nt to an extensi on
object, the f unction shall return a null pointer.
w) The methods clear_extension(const T* ) and clear_extension() shal l remove the gi ven extension
f rom the generic payl oad object, that is, shall set the corresponding pointer in the extensi on array to
null . The extension may be speci f ied either by passing a pointer to an extensi on object as an
argument or by usi ng the f unction templ ate parameter type, for example,
clear_extension<ext_type>(). If present, the argument shall be a pointer to an object of a type
derived from tlm_extension. Method clear_extension shall not del ete the extensi on object.
x) The methods release_extension(T* ) and release_extension() shall mark the extension for
automati c del etion if the transaction object has a memory manager or otherwi se shall delete the
given extensi on by cal li ng the method free of the extensi on object and setting the corresponding
pointer i n the extensi on array to null. The extension may be specif ied ei ther by passi ng a poi nter to
an extension obj ect as an argument, or by using the function template parameter type, f or example,
release_extension<ext_type>(). If present, the argument shall be a poi nter to an object of a type
derived from tlm_extension.
y) Note that the behavior of method release_extension depends on whether or not the transaction
object has a memory manager. Wi th a memory manager, the extension i s merely marked f or
automati c deleti on, and conti nues to be accessi ble. I n the absence of a memory manager, not onl y is
the extension pointer cl eared but al so the extension obj ect itself is del eted. Care shoul d be taken not
to rel ease a non-exi stent extension obj ect because doing so wi ll resul t i n a run-time error.
z) The methods clear_extension and release_extension shall not be call ed f or extensions marked for
automati c del etion, for exampl e, an extensi on set using set_auto_extension or al ready released
usi ng release_extension. Doing so may resul t in a run-time error.
aa) Each generic payl oad transacti on shoul d al locate suf fi ci ent space to store pointers to every
regi stered extensi on. This can be achieved i n one of two ways, either by constructi ng the transaction
object after C++ static ini ti al izati on or by call ing the method resize_extensions after stati c
ini ti al ization but before using the transaction obj ect for the f irst ti me. In the f ormer case, i t is the
responsibi lity of the generic payl oad constructor to set the si ze of the extension array. I n the latter
case, i t i s the responsibil ity of the appl icati on to call resize_extensions bef ore accessing the
extensi ons for the f irst ti me.
ab) The method resize_extensionsshal l increase the size of the extensi ons array in the generi c payload
to accommodate every registered extension.
Exampl e:
// Showing an ignor able extension
// User-defi ned extensi on class
struct I D_extension: tlm::tlm_extension<I D_extensi on>
{
I D_extension() : transaction_id(0) { }
virtual tlm_extension_base* clone() const { // Must overri de pure virtual clone method
ID_extensi on* t = new ID_extensi on;
t->transaction_id = thi s->transaction_i d;
return t;
}
// Must overri de pure vi rtual copy_from method
virtual voi d copy_from(tlm_extension_base const & ext) {
transaction_id = stati c_cast<ID_extensi on const &>(ext).transacti on_i d;
}
unsi gned int transacti on_id;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


498
Copyright 2012 IEEE. All rights reserved.
} ;
// The i ni ti ator
struct I nitiator: sc_module
{ ...
void thread() {
tlm::tlm_gener ic_payload trans;
...
I D_extension* i d_extensi on = new ID_extensi on;
trans.set_extension( i d_extensi on ); // Add the extensi on to the transacti on
f or (i nt i = 0; i < RUN_LENGTH; i += 4) {
...
++ id_extension->transacti on_i d; // Increment the id f or each new transacti on
...
socket->b_transport(trans, delay);
...
// The target
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_core::sc_time& t)
{ ...
I D_extensi on* id_extension;
trans.get_extension( i d_extensi on ); // Retri eve the extension
if (i d_extensi on) { // Extensi on i s not mandatory
char txt[ 80] ;
sprintf(txt, "Recei ved transaction id %d", id_extension->transacti on_i d);
SC_REPORT_INFO("TLM-2.0", txt);
}
...
// Showing a new protocol traitsclasswith a mandatory extension
struct cmd_extensi on: tlm::tlm_extension<cmd_extension>
{ // User-defi ned mandatory extensi on class
cmd_extensi on(): increment(fal se) { }
virtual tlm_extension_base* clone() const {
cmd_extension* t = new cmd_extension;
t->increment = thi s->increment;
return t;
}
virtual void copy_from(tlm_extension_base const & ext) {
increment = stati c_cast<cmd_extension const &>(ext).increment;
}
bool increment;
} ;
struct my_protocol_types // User-defi ned protocol trai ts cl ass
{
typedef tlm::tlm_generic_payl oad tl m_payl oad_type;
typedef tlm::tlm_phase tl m_phase_type;
} ;
struct I nitiator: sc_module
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


499
Copyright 2012 IEEE. All rights reserved.
tl m_uti ls::si mple_initiator_socket<I nitiator, 32, my_protocol_types> socket;
...
void thread() {
tlm::tlm_gener ic_payload trans;
cmd_extension* extensi on = new cmd_extensi on;
trans.set_extension( extensi on ); // Add the extension to the transaction
...
trans.set_command(tlm::TLM_WRITE_COMMAND); // Execute a wri te command
socket->b_transport(trans, delay);
...
trans.set_command(tlm::TLM_I GNORE_COMMAND);
extensi on->increment = true; // Execute an increment command
socket->b_transport(trans, delay);
...
...
// The target
tl m_uti ls::si mple_target_socket<Memory, 32, my_protocol_types> socket;
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_core::sc_time& t)
{
tl m::tlm_command cmd = trans.get_command();
...
cmd_extension* extension;
trans.get_extension( extensi on ); // Retri eve the command extension
...
if (! extension) { // Check the extension exi sts
trans.set_response_status( tl m::TLM_GENERI C_ERROR_RESPONSE );
return;
}
if (extensi on->increment) {
if (cmd != tlm::TLM_I GNORE_COMMAND) { // Detect cl ash with read or write
trans.set_response_status( tl m::TLM_GENERI C_ERROR_RESPONSE );
return;
}
++ m_storage[ adr] ; // Execute an i ncrement command
memcpy(ptr, & m_storage[ adr], l en);
}
...
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


500
Copyright 2012 IEEE. All rights reserved.
15. TLM-2.0 base protocol and phases
15.1 Phases
15.1.1 Introduction
Cl ass tlm_phase is the default phase type used by the non-blocking transport interface class templates and
the base protocol. A tlm_phase object represents the phase with an unsigned int value. Class tlm_phase is
assignment compatibl e wi th type unsigned int and with an enumeration having val ues corresponding to the
f our phases of the base protocol, namely BEGI N_REQ, END_REQ, BEGI N_RESP, and END_RESP.
Because type tlm_phase is a cl ass rather than an enumerati on, it is able to support an overloaded stream
operator to display the val ue of the phase as ASCII text.
The set of four phases provided by tlm_phase_enum can be extended using the macro
TLM_DECLARE_EXTENDED_PHASE. Thi s macro creates a si ngl eton class deri ved f rom tlm_phase
wi th a method get_phase that returns the correspondi ng object. That obj ect can be used as a new phase.
For maximal interoperabil ity, an appli cati on shoul d only use the four phases of tlm_phase_enum. If further
phases are requi red in order to model the detail s of a specif ic protocol, the i ntent i s that
TLM_DECLARE_EXTENDED_PHASE should be used si nce this retai ns assi gnment compati bi li ty wi th
type tlm_phase.
The principl e of ignorable versus non-i gnorabl e or mandatory extensi ons appl ies to phases in the same way
as to generic payl oad extensions. I n other words, i gnorabl e phases are permitted by the base protocol . An
ignorable phase has to be i gnorable by the recipi ent in the sense that the recipi ent can simpl y act as i f i t had
not recei ved the phase transi tion, and consequentl y, the sender has to be able to continue i n the absence of
any response from the recipi ent. If a phase i s not ignorabl e i n thi s sense, a new protocol traits class shoul d be
def ined (see 14.2.2).
15.1.2 Class definition
namespace tl m {
enum tlm_phase_enum {
UNI NITI ALI ZED_PHASE=0, BEGI N_REQ=1, END_REQ, BEGIN_RESP, END_RESP } ;
class tlm_phase{
publ ic:
tlm_phase();
tlm_phase( unsigned int );
tlm_phase( const tl m_phase_enum& );
tl m_phase& oper ator = ( const tlm_phase_enum& );
oper ator unsigned int() const;
} ;
inl ine std::ostream& oper ator << ( std::ostream& , const tlm_phase& );
#def ine TLM _DECLARE_EXTENDED_PHASE(name_arg) \
class tlm_phase_##name_arg : publi c tlm::tlm_phase{ \
publ ic:\
stati c const tlm_phase_##name_arg& get_phase();\
impl ementation-def ined \
} ; \
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


501
Copyright 2012 IEEE. All rights reserved.
stati c const tlm_phase_##name_arg& name_ar g=tlm_phase_##name_arg::get_phase()

} // namespace tl m
15.1.3 Rules
a) The default constructor tlm_phase shall set the value of the phase to 0, correspondi ng to the
enumeration li teral UNI NI TIALI ZED_PHASE.
b) The methods tlm_phase( unsigned int), oper ator = and oper ator unsigned int shal l get or set the
val ue of the phase usi ng the correspondi ng unsi gned int or enum.
c) The functi on oper ator << shall write a character stri ng corresponding to the name of the phase to the
given output stream. For example, "BEGIN_REQ".
d) The macro TLM_DECLARE_EXTENDED_PHASE(name_arg) shall create a new si ngl eton class
named tlm_phase_name_ar g, deri ved from tlm_phase, and havi ng a public method get_phase that
returns a ref erence to the stati c object so created. The macro argument shal l be used as the character
string wri tten by oper ator << to denote the corresponding phase.
e) The invocati on of the macro TLM_DECLARE_EXTENDED_PHASE shal l be terminated wi th a
semicol on.
f ) The i ntent i s that the obj ect denoted by the stati c const name_ar g represents the extended phase that
may be passed as a phase argument to nb_transport.
Exampl e:
TLM_DECLARE_EXTENDED_PHASE(ignore_me); // Decl are two extended phases
TLM_DECLARE_EXTENDED_PHASE(internal _ph); // Onl y used wi thin target
struct I nitiator: sc_module
{ ...
{ ...
phase = tlm::BEGIN_REQ;
del ay = sc_time(10, SC_NS);
socket->nb_transport_f w( trans, phase, delay ); // Send phase BEGIN_REQ to target
phase = ignore_me; // Set phase vari abl e to the extended phase
del ay = sc_time(12, SC_NS);
socket->nb_transport_f w( trans, phase, delay ); // Send the extended phase 2ns l ater
...
struct Target: sc_module
{
...
SC_CTOR(Target)
: m_peq("m_peq", thi s, &Target::peq_cb) { } // Register call back with PEQ
virtual tlm::tlm_sync_enum nb_transport_f w( tlm::tlm_generic_payload& trans,
tl m::tlm_phase& phase, sc_time& delay ) {
cout << "Phase = " << phase << endl ; // use overloaded operator<< to print phase
m_peq.noti fy(trans, phase, del ay); // Move transaction to internal queue
return tl m::TLM_ACCEPTED;
}
void peq_cb(tl m::tl m_generi c_payload& trans, const tl m::tlm_phase& phase)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


502
Copyright 2012 IEEE. All rights reserved.
{ // PEQcall back
sc_timedel ay;
tl m::tlm_phasephase_out;
if (phase== tl m::BEGIN_REQ) { // Recei ved BEGIN_REQfromi niti ator
phase_out = tlm::END_REQ;
del ay = sc_time(10, SC_NS);
socket->nb_transport_bw(trans, phase_out, del ay); // Send END_REQback to ini ti ator
phase_out = internal_ph; // Useextended phaseto signal internal event
del ay = sc_time(15, SC_NS);
m_peq.noti fy(trans, phase_out, delay); // Put internal event into PEQ
}
elsei f (phase== internal_ph) // Received internal event
{
phase_out = tlm::BEGIN_RESP;
del ay = sc_time(10, SC_NS);
socket->nb_transport_bw(trans, phase_out, delay); // SendBEGIN_RESPback to initiator
}
} // Ignorephasei gnore_mefromini ti ator
tl m_uti ls::peq_with_cb_and_phase<Target, tlm::tlm_base_protocol_types> m_peq;
} ;
15.2 Base protocol
15.2.1 Introduction
The base protocol consists of a set of rul es to ensure maximal interoperabil ity between transaction l evel
model s of components that interface to memory-mapped buses. The base protocol requi res the use of the
classesof theTLM-2.0i nteroperabil ity l ayer l isted here, together wi th therules definedi n this cl ause:
a) TheTLM-2.0 coretransport, direct memory, and debug transport i nterfaces(seeClause11).
b) Thesocket cl assestlm_initiator_socket and tlm_target_socket (or classesderivedfromthese) (see
13.2).
c) Thegeneric payl oad class tlm_generic_payload (seeCl ause14).
d) Thephaseclass tl m_phase.
Thebaseprotocol rules permi t extensions to thegeneric payload and to thephases only i f thoseextensi ons
areignorable. Non-ignorableextensionsrequirethedefi nition of anew protocol traitscl ass(see14.2.1).
The base protocol is represented by the pre-defined cl ass tlm_base_protocol_types. However, thi s class
contai ns nothi ng but two type defi ni ti ons. Al l components that use thi s cl ass (as templ ate argument to a
socket) areobli ged by conventi onto respect therul esof thebaseprotocol.
In cases where i t is necessary to define a new protocol traits class (e.g., because the features of the base
protocol are i nsuffici ent to model a particular protocol), the rules associated wi th the new protocol traits
class overridethoseof thebase protocol. However, for consistency and interoperabi lity, i t isrecommended
that therulesand coding styl eassociated wi th any new protocol traits class shoul d follow thoseof thebase
protocol asfar aspossi bl e(see14.2.2).
This secti on of the standard speci fi call y concerns the base protocol , but nonethel ess it may be used as a
guide when model ing other protocol s. Speci fi c protocols represented by other protocol traits classes may
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


503
Copyright 2012 IEEE. All rights reserved.
include addi ti onal phases and may adopt thei r own rules f or timi ng annotation, transaction orderi ng, and so
f orth. In doing so, they may cease to be compati ble wi th the base protocol .
15.2.2 Class definition
namespace tl m {
struct tlm_base_protocol_types
{
typedef tlm_generic_payload tlm_payload_type;
typedef tlm_phase tlm_phase_type;
} ;
} // namespace tl m
15.2.3 Base protocol phase sequences
a) The base protocol permits the use of the blocking transport interface, the non-blocki ng transport
interface, or both together. The blocking transport interface does not carry phase inf ormati on. When
used with the base protocol, the constrai nts governing the order of cal ls to nb_transpor t are stronger
than those governi ng the order of cal ls to b_tr anspor t. Hence nb_transpor t is more f or the
approxi mately-ti med codi ng styl e, and b_tr anspor t is more f or the loosely-ti med coding styl e.
b) The f ull sequence of phase transitions f or a given transacti on through a given socket i s:
BEGI N_REQ -> END_REQ -> BEGI N_RESP -> END_RESP
c) BEGI N_REQ and END_RESP shall be sent through i nitiator sockets onl y, and END_REQ and
BEGI N_RESP through target sockets onl y.
d) I n the case of the blocki ng transport interface, a transaction i nstance i s associ ated wi th a si ngl e cal l
to and return f rom b_tr anspor t. The correspondence between the call to b_tr anspor t and
BEGI N_REQ, and the return from b_tr anspor t and BEGIN_RESP, is purel y noti onal ; b_tr anspor t
has no associated phases.
e) For the base protocol , each cal l to nb_transpor t and each return f rom nb_transpor t with a val ue of
TLM_UPDATED shall cause a phase transi tion. I n other words, two consecutive calls to
nb_transpor t for the same transacti on shall have dif ferent values f or the phase argument. I gnorable
phase extensi ons are permitted, i n which case the insertion of an extended phase shal l count as a
phase transi ti on f or the purposes of this rul e, even i f the phase i s i gnored.
f ) The phase sequence can be cut short by having nb_transpor t return a val ue of TLM_COMPLETED
but onl y in one of the f oll owing ways (Fi gure 28). An interconnect component or target may return
TLM_COMPLETED when it recei ves BEGIN_REQ or END_RESP on the forward path. An
interconnect component or ini ti ator may return TLM_COMPLETED when it receives
BEGI N_RESP on the backward path. A return value of TLM_COMPLETED i ndicates the end of
the transaction wi th respect to a parti cular hop, in whi ch case the phase argument shoul d be i gnored
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


504
Copyright 2012 IEEE. All rights reserved.
by the call er (see 11.1.2.7). TLM_COMPLETED does not impl y successf ul compl etion, so the
ini ti ator should check the response status of the transaction for success or f ail ure.
Figure 28Examples of early completion
g) A transiti on to the phase END_RESP shal l al so indicate the end of the transaction wi th respect to a
parti cul ar hop, in whi ch case the call ee i s not obl iged to return a value of TLM_COMPLETED.
h) When TLM_COMPLETED i s returned in an upstream directi on after havi ng received
BEGI N_REQ, thi s carries wi th i t an i mpli cit END_REQ and an impl ici t BEGI N_RESP. Hence, the
ini ti ator should check the response status of the generic payload, and may send BEGIN_REQ f or the
next transaction immediatel y.
i) Since TLM_COMPLETED returned after having received BEGI N_REQ carries wi th it an i mpli ci t
BEGI N_RESP, this situati on is forbidden by the response exclusion rul e if there is already a
response i n progress through a gi ven socket. In thi s situati on, the callee should have returned
TLM_ACCEPTED i nstead of TLM_COMPLETED and should wait f or END_RESPbefore sending
the next response upstream.
j) Since TLM_COMPLETED returned after havi ng recei ved BEGIN_REQ i ndi cates the end of the
transaction, an i nterconnect component or i nitiator i s f orbidden f rom then sendi ng END_RESP f or
that same transacti on through that same socket.
k) When TLM_COMPLETED is returned in a downstream di rection by a component after havi ng
received BEGI N_RESP, this carri es wi th it an impl icit END_RESP.
l) I f a component recei ves a BEGI N_RESP f rom a downstream component wi thout havi ng fi rst
received an END_REQ for that same transaction, the initiator shal l assume an i mpli cit END_REQ
immedi ately preceding the BEGIN_RESP. This i s only the case for the same transacti on; a
BEGI N_RESP does not impl y an END_REQ for any other transaction, and a target that recei ves a
BEGI N_REQ cannot inf er an END_RESP for the previous transaction.
m) The above points hol d regardless of the val ue of the timing annotati on argument to nb_transpor t.
n) A base protocol transacti on i s compl ete (wi th respect to a particular hop) when
TLM_COMPLETED is returned on ei ther path, or when END_RESP is sent on the forward path or
the return path.
I nitiator Tar get
Cal l
Retur n
-, BEGIN_REQ, 0ns
TLM_COMPLETED, -, -
Cal l
Retur n TLM_ACCEPTED, -, -
Cal l
Retur n
TLM_COMPLETED, -, -
-, BEGIN_REQ, 0ns
-, BEGIN_RESP, 0ns
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


505
Copyright 2012 IEEE. All rights reserved.
o) I n the case where END_RESP i s sent on the f orward path, the call ee may return TLM_ACCEPTED
or TLM_COMPLETED. The transaction is compl ete in either case.
p) A gi ven transaction may complete at dif ferent ti mes on dif ferent hops. A transaction object passed to
nb_transpor t is obl iged to have a memory manager, and the l if etime of the transacti on object ends
when the ref erence count of the generi c payl oad reaches zero. Any component that cal ls the acquire
method of a generi c payl oad transaction object should al so cal l the release method at or bef ore the
completi on of the transacti on (see 14.5).
q) I f a component receives an i ll egal or out-of-order phase transi ti on, this i s an error on the part of the
sender. The behavior of the recipient i s undef ined, meaning that a run-time error may be caused.
15.2.4 Permitted phase transitions
Taki ng all of the rules i n the previous clause into account, the set of permitted phase transiti ons over a given
hop f or the base protocol is shown in Tabl e 57.
Table 57Permitted phase transitions
P
r
e
v
i
o
u
s
s
t
a
t
e
C
a
ll
i
n
g
p
a
t
h
P
h
a
s
e
a
r
g
u
m
e
n
t
o
n

c
a
l
l
P
h
a
s
e

a
r
g
u
m
e
n
t
o
n
r
e
t
u
r
n
S
t
a
t
u
s
o
n
r
e
t
u
r
n
R
e
s
p
o
n
s
e

v
a
l
i
d
E
n
d
-
o
f
-
l
i
f
e
N
e
x
t

s
t
a
t
e
//rsp Forward BEGI N_REQ - Accepted req
//rsp Forward BEGI N_REQ END_REQ Updated //req
//rsp Forward BEGI N_REQ BEGI N_RES
P
Updated X rsp
//rsp Forward BEGI N_REQ - Compl eted X X //rsp
req Backward END_REQ - Accepted //req
req Backward BEGI N_RESP - Accepted X rsp
req Backward BEGI N_RESP END_RESP Updated X X //rsp
req Backward BEGI N_RESP - Compl eted X X //rsp
//req Backward BEGI N_RESP - Accepted X rsp
//req Backward BEGI N_RESP END_RESP Updated X X //rsp
//req Backward BEGI N_RESP - Compl eted X X //rsp
rsp Forward END_RESP - Accepted X X //rsp
rsp Forward END_RESP - Compl eted X X //rsp
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


506
Copyright 2012 IEEE. All rights reserved.
a) req, //req, rsp, //rsp stand for BEGIN_REQ, END_REQ, BEGIN_RESP, and END_RESP, respec-
ti vel y.
b) These phase state transitions are i ndependent of the val ue of the sc_time argument to nb_transpor t
(the timi ng annotation). In other words, a call to nb_transpor t wil l cause the state transiti on shown
in the table regardl ess of the value of the ti ming annotation. (The timing annotation may have the
eff ect of del ayi ng the subsequent executi on of the transaction.)
c) The previousstate col umn shows the state of a given hop bef ore a call to nb_transpor t.
d) The calling path column i ndi cates whether the correspondi ng method is cal led on the f orward path
(nb_tr ansport_fw) or backward path (nb_tr ansport_bw).
e) The phase argument on call column gives the val ue of the phase argument on the call to
nb_transpor t. This wil l be the phase presented to the call ee.
f ) The phase argument on retur n col umn gives the val ue of the phase argument on return f rom
nb_transpor t. The phase argument i s onl y vali d i f the method returns TLM_UPDATED.
g) The status on retur n column gives the return value of the nb_transpor t method, Accepted
(TLM_ACCEPTED), Updated (TLM_UPDATED), or Compl eted (TLM_COMPLETED).
h) The response valid col umn is checked i f the response status attribute of the transacti on i s val id on
return from the nb_transpor t method.
i) The end-of-life column i s checked if the transaction has reached the end of its l if etime with respect
to thi s hop, that i s, i f no further nb_transpor t cal ls are permitted for the gi ven transacti on over the
given hop.
j) The next state col umn shows the state of a given hop af ter return f rom nb_transpor t.
k) A phase transi ti on can be caused ei ther by the call er (indicated by a '-' i n the phase argument on
return col umn) or by the call ee.
l ) I gnorable phase extensions may be i nserted at any point between BEGIN_REQ and END_RESP.
m) A val id response does not indicate successf ul completi on. The transacti on may or may not have been
successful .
n) Figure 29 presents, in a graphical format, the nb_transpor t call sequences permitted by the base
protocol over a given hop. A traversal of the graph f rom Start to End gives a permitted cal l sequence
f or a single transaction i nstance. The rectangles show call s to nb_transpor t together with the val ue
of the phase argument, the rounded rectangl es show the status and where appropri ate the value of the
phase argument on return. The larger shaded rectangles show phase transi ti ons.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


507
Copyright 2012 IEEE. All rights reserved.
Figure 29nb_transport call sequence for each base protocal transaction
nb_transport_bw/END_REQ TLM_UPDATED/END_REQ
nb_transport_bw/BEGIN_RESP
TLM_ACCEPTED
TLM_ACCEPTED
TLM_UPDATED/BEGIN_RESP
nb_transport_fw/BEGIN_REQ
TLM_UPDATED/END_RESP
TLM_ACCEPTED
nb_transport_fw/END_RESP
TLM_COMPLETED TLM_ACCEPTED
End
Start
Return
Phase Transiti on
Cal l Legend:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


508
Copyright 2012 IEEE. All rights reserved.
15.2.5 Ignorable phases
Extended phases may be used with the base protocol provided that they are i gnor abl e phases. An i gnorabl e
phase may be i gnored by its reci pi ent.
a) I n general , the recommended way to add extended phases to the four phases of the base protocol i s
to def ine a new protocol traits cl ass (see 14.2.2). I gnorable phases are a speci al and restri cted case of
extended phases. The main purpose of i gnorabl e phases is to permit extra ti ming points to be added
to the base protocol in order to increase the ti mi ng accuracy of the model. For example, an ignorable
phase could mark the ti me of the start of the data transf er from ini tiator to target.
b) I n the case of a cal l to nb_transpor t, i f it i s the call ee that is ignoring the phase, it shall return a val ue
of TLM_ACCEPTED. In the case that the call ee returns TLM_UPDATED, the call er may ignore
the phase bei ng passed on the return path but i s not obli ged to take any specif ic acti on to indicate
that the phase is bei ng i gnored.
c) The nb_transpor t interf ace does not provi de any way for the call er of nb_transpor t to distingui sh
between the case where the cal lee is ignoring the phase, and the case where the cal lee wi ll respond
later on the opposite path. The call ee shall return TLM_ACCEPTED in ei ther case.
d) The presence of an ignorable phase shal l not change the order or the semantics of the four phases
BEGI N_REQ, END_REQ, BEGI N_RESP, and END_RESP of the base protocol, and is not
permi tted to result in any of the rules of the base protocol being broken.
e) An ignorable phase shal l not occur before BEGI N_REQ or af ter END_RESP for a given transacti on
through a given socket. The presence of an ignorabl e phase bef ore BEGI N_REQ or after
END_RESP woul d vi olate the base protocol , and is an error.
f ) The presence of an ignorable phase shall not change the rules concerning the vali dity of the generic
payl oad attributes or the rules for modif ying those attri butes. For example, on receipt of an ignorable
phase, an interconnect component is onl y permi tted to modi fy the address attribute, DMI all owed
attri bute, and extensi ons (see 14.7).
g) Wi th the excepti on of transparent components as defi ned below, if the recipi ent of an ignorable
phase does not recogni ze that phase (that is, the phase i s being i gnored), the recipi ent shal l not
propagate that phase on the forward, the backward, or the return path. I n other words, a component
is only permi tted to pass a phase as an argument to an nb_transpor t cal l i f i t f ully understands the
semanti cs of that phase.
h) I f the reci pi ent of an i gnorable phase does recogni ze that phase, provi ded that the base protocol i s
not vi ol ated, the behavi or of that component is otherwi se outside the scope of the base protocol and
is undef ined by the base protocol. The reci pient shoul d obey the semantics of the extended protocol
to whi ch the phase belongs.
i ) By defi niti on, a component that sends an i gnorabl e phase cannot requi re or demand any kind of
response f rom the components to whi ch that phase i s sent other than the mini mal response of
nb_transpor t returni ng a value of TLM_ACCEPTED. A phase that demands a response is not
ignorable, by def inition, i n which case the recommended approach is to def ine a new protocol traits
class rather than using extensi ons to the base protocol. This prevents the binding of sockets that
represent incompati bl e protocol s.
j ) On the other hand, a base-protocol -compli ant component that does recognize an incoming extended
phase may respond by sendi ng another extended phase on the opposi te path according to the rules of
some extended protocol agreed in advance. This possibil ity is permitted by the TLM-2.0 standard,
provided that the rul es of the base protocol are not broken. For example, such an extended protocol
coul d make use of generic payload extensions.
k) I t i s possi bl e to create so-cal led tr ansparent i nterconnect components, which immedi ately and
directly pass through any TLM-2.0 interface method cal ls between a target socket and an i niti ator
socket contained wi thi n the same component. The sol e i ntent of recogni zing transparent components
in this standard i s to all ow for checkers and moni tors, whi ch typi cal ly have one target socket, one
ini ti ator socket, and pass through all transacti ons in both directi ons without modifi cation.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


509
Copyright 2012 IEEE. All rights reserved.
l) Wi thi n a transparent component, the i mplementati on of any TLM-2.0 core interface method shal l
not consume any si mulati on time, i nsert any del ay, or call wait, but shal l immediatel y make the
identi cal i nterface method call through the opposi ng socket (i ni ti ator socket to target socket or target
socket to i ni ti ator socket), passi ng through all i ts arguments. Such an i nterf ace method shall not
modif y the value of any argument, including the transacti on obj ect, the phase, and the del ay, wi th
the one excepti on of generi c payl oad extensi ons. The routi ng through such transparent components
shal l be f ixed, and not depend on transaction attributes or phases.
m) As a consequence of the above rul es, a transparent component would pass through any extended
phase or ignorable phase i n either direction.
Exampl e:
Figure 30Ignorable phases
An exampl e of an i gnorabl e phase generated by an ini tiator would be a phase to mark the f irst beat of the
data transfer f rom the initiator in the case of a write command (Fi gure 30). An i nterconnect component or
target that recogni zed thi s phase coul d disti ngui sh between the time at which the command and address
become avai lable and the start of the data transfer. A target that ignored this phase woul d have to use the
BEGI N_REQ phase as i ts si ngl e timi ng reference f or the avail abi li ty of the command, address, and data.
An exampl e of an i gnorabl e phase generated by a target would be a phase to mark a spli t transacti on. An
ini ti ator that recognized this phase coul d send the next request immediately on recei ving the spl it phase,
knowing that the target woul d be ready to process i t. An i ni ti ator that ignored the spl it phase mi ght wai t until
it had received a response to the f irst request before sending the second request.
I nitiator Tar get
BEGI N_REQ
END_REQ
BEGI N_DATA (ignored)
SPLIT(ignored)
BEGI N_RESP
END_RESP
BEGI N_REQ(af ter RESP)
END_REQ
BEGI N_REQ
END_REQ
BEGI N_DATA (used)
SPLIT(used)
END_REQ
BEGI N_RESP
END_RESP
I nitiator Tar get
BEGI N_REQ (sent earl y)
Ti mi ng
reference
for
response
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


510
Copyright 2012 IEEE. All rights reserved.
15.2.6 Base protocol timing parameters and flow control
a) With four phases, it is possi bl e to model the request accept delay (or mi nimum i ni ti ation interval
between sendi ng successive transactions), the l atency of the target, and the response accept del ay.
Thiski nd of ti ming granul arity isappropri atefor theapproxi mately-timed codi ngstyl e(Figure31).
Figure 31Approximately-timed timing parameters
b) For awri tecommand, theBEGIN_REQphasemarksthetimewhen thedatabecomes avail abl efor
transfer from initiator through i nterconnect component to target. Notionall y, the transition to the
BEGIN_REQ phase corresponds to the start of the first beat of the data transfer. It is the
responsibi li ty of the downstreamcomponent to cal cul ate the transfer time, and to send END_REQ
back upstreamwhen it i s ready to recei vethenext transfer. It would be natural for the downstream
component to del ay the END_REQ until the end of the final beat of the data transfer, but i t is not
obli ged to doso.
c) For aread command, theBEGIN_RESPphasemarksthetimewhen thedatabecomes avai lablefor
transfer from target through i nterconnect component to i nitiator. Noti onall y, the transi ti on to the
BEGIN_RESP phase corresponds to the start of the first beat of the data transfer. It i s the
responsibi li ty of the upstream component to cal culate the transfer time, and to send END_RESP
back downstreamwhen it is ready to recei vethenext transfer. It would be natural for the upstream
component to del ay the END_RESPunti l the end of the fi nal beat of the datatransfer, but i t i s not
obli ged to doso.
d) For a read command, if a downstream component completes a transaction earl y by returni ng
TLM_COMPLETED fromnb_transport_fw, it i s theresponsi bi li ty of theupstreamcomponent to
account for thedatatransfer ti mein someother way, if it wishesto do so (sincei t i snot permitted to
send END_RESP).
e) For the base protocol, an i ni ti ator or interconnect component shal l not send a new transaction
through agiven socket wi th phase BEGIN_REQunti l i t has received END_REQor BEGIN_RESP
fromthedownstreamcomponent for thei mmediatel y precedi ngtransacti onor until thedownstream
component has completed the previous transaction by returni ng the value TLM_COMPLETED
fromnb_transport_fw. This isknown as ther equest excl usi on rul e.
BEGI N_REQ
END_REQ
BEGI N_RESP
END_RESP
I nitiator Target
Request accept delay
Latency of target
Responseaccept delay
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


511
Copyright 2012 IEEE. All rights reserved.
f) For the base protocol , a target or i nterconnect component shall not respond to a new transacti on
through a gi ven socket with phase BEGIN_RESP until it has received END_RESP from the
upstreamcomponent for thei mmediatel y preceding transaction or unti l acomponent hascompleted
the previous transaction over that hop by returni ng TLM_COMPLETED. This i s known as the
r esponse excl usi on r ul e.
g) Al l therulesgoverning phase transitions, i ncl udi ng the request and response exclusion rul es, shal l
bebased on methodcal l order alone, and shall not beaffectedby theval ueof thetimeargument (the
ti mi ng annotation).
h) Successive transactions sent through agi ven socket usi ng thenon-bl ocking transport i nterface can
be pi pel ined. By responding to each BEGIN_REQ (or BEGIN_RESP) wi th an END_REQ (or
END_RESP), an i nterconnect component can permit any number of transaction objects to be in
fl i ght at the same ti me. By not responding immedi ately wi th END_REQ (or END_RESP), an
interconnect component can exerci se fl ow control over the stream of transacti on obj ects comi ng
fromani niti ator (or target).
i ) This rule excluding thepossibi li ty of two outstanding requestsor responsesthrough agiven socket
shal l only apply to the non-blocki ng transport interface, and shal l have no di rect effect on call s to
b_transport (Fi gure32 and Fi gure33). (The rule may have an i ndi rect effect on a cal l to
b_transport in thecasethat b_transport itsel f cal ls nb_transport_fw.)
j) For agi ven transaction, BEGIN_REQshall al waysstart froman ini ti ator and bepropagated through
zero or more interconnect components until it is received by a target. For a gi ven transaction, an
interconnect component is not permitted to send BEGIN_REQto adownstreamcomponent before
havi ngreceived BEGIN_REQfromanupstreamcomponent.
k) For a given transaction, BEGIN_RESPshall al ways start froma target and be propagated through
zero or moreinterconnect componentsuntil it isrecei ved by ani nitiator. For agi ven transaction, an
interconnect component is not permitted to send BEGIN_RESP to an upstreamcomponent before
havi ng received BEGIN_RESP from a downstream component. This appli es whether
BEGIN_RESPi sexpli ci t or i si mpli edby TLM_COMPLETED.
l) For agiven transacti on, an interconnect component may send END_REQto anupstreamcomponent
before havi ng received END_REQ from a downstream component. Simi larl y, an interconnect
component may send END_RESPto adownstreamcomponent beforehaving received END_RESP
from an upstream component. This appl ies whether END_REQ and END_RESP are expli ci t or
impl icit.
m) END_REQ and END_RESP are primaril y for flow control between adj acent components. These
two phasesdo not si gnal the vali dity of any standard generi c payl oad attributes. Becausethesetwo
phases are not propagated causal ly from end-to-end, they cannot reliably be used to signal the
val idi ty of extensi ons fromini ti ator-to-target or target-to-initiator, but they can beused to signal the
val idi ty of extensionsbetween two adjacent components.
n) Whether or not an interconnect component is permitted to send an extended phase before havi ng
received, the correspondi ng phase depends on the rul es associated with the extended phase in
questi on.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


512
Copyright 2012 IEEE. All rights reserved.
Figure 32Causality with b_transport
Figure 33Causality with nb_transport
Initiator
attributes
sets
Initiator
checks
response
Modifies
address
Target
attributes
modifi es
Modifies
address
return
b_transport
b_transport
b_transport
return
return
I nitiator I nterconnect Tar get I nterconnect
Initiator
attributes
sets
Initiator
checks
response
Target
attributes
modifi es
BEGI N_RESP
BEGI N_REQ
END_REQ Req i n progress
END_RESP
Resp i n progress
I nitiator I nterconnect Tar get I nterconnect
Req i n progress
Req i n progress
BEGI N_RESP
BEGI N_RESP
END_RESP
END_RESP
BEGI N_REQ
BEGI N_REQ
Resp i n progress
Resp i n progress
END_REQ
END_REQ
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


513
Copyright 2012 IEEE. All rights reserved.
Exampl e:
The foll owing pseudo-code il lustrates the i nteraction between timing annotation and the request and
response exclusion rules:
void initiator_1_thread_process()
{
// The i ni ti ator sends a request to be executed at +1000ns
phase = BEGIN_REQ; delay = sc_ti me(1000, SC_NS);
status = socket->nb_transport_fw (T1, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_ti me(1010, SC_NS) );
// END_REQ is returned immedi ately to be executed at +1010ns

// Note that thi s i s not a recommended coding style
// Wi th loosel y-ti med, the i ni ti ator would have cal led b_transport
// Wi th approxi mately-ti med, the downstream component woul d have returned TLM_ACCEPTED
// in order to synchronize, and the initiator woul d have been f orced to wai t f or END_REQ
// The i ni ti ator i s all owed to send the next request immedi ately, to be executed at +1050ns
phase = BEGIN_REQ; delay = sc_ti me(1050, SC_NS);
status = socket->nb_transport_fw (T2, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_ti me(1060, SC_NS) );
// The i ni ti ator i s technical ly all owed to send the next request at an earl ier l ocal time of +500ns,
// although the decreased ti mi ng annotation i s not a recommended codi ng style
phase = BEGIN_REQ; del ay = sc_ti me(500, SC_NS);
status = socket->nb_transport_fw (T3, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_ti me(510, SC_NS) );
// The i ni ti ator now yields control, al lowi ng other i niti ators to resume and si mulati on time to advance
wait();
}
void initiator_2_thread_process()
{
// Assume the call s below are appended to the transaction stream sent f rom the f irst initiator above
// The second i niti ator sends a request to be executed at +10ns
// The timi ng annotation as seen downstream has decreased f rom +510ns to +10ns
// This is typical behavior f or loosel y-ti med i nitiators
phase = BEGIN_REQ; del ay = sc_ti me(10, SC_NS);
status = socket->nb_transport_fw (T4, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_time(30, SC_NS) );
// END_REQ is returned immedi ately to be executed at +30ns
// The initiator sends the next request to be executed at +20ns, which overl aps with the previ ous request
// This is techni cal ly al lowed because the current phase of the hop is END_REQ,
// but is not recommended
phase = BEGIN_REQ; del ay = sc_ti me(20, SC_NS);
status = socket->nb_transport_fw (T5, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_time(40, SC_NS) );
// END_REQ is returned immedi ately to be executed at +40ns
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


514
Copyright 2012 IEEE. All rights reserved.
// The initiator sends the next request to be executed at +0ns, which is bef ore the previ ous two requests
// This is technicall y al lowed because the current phase of the hop is END_REQ,
// but is not recommended
phase = BEGIN_REQ; del ay = sc_ti me(0, SC_NS);
status = socket->nb_transport_fw (T6, phase, del ay);
assert( status == TLM_UPDATED && phase == END_REQ && delay == sc_time(60, SC_NS) );
// END_REQ is returned immedi ately to be executed at +60ns, overl appi ng the two previ ous requests
// This i s technicall y all owed, but i s not recommended
wait();
}
15.2.7 Base protocol rules concerning timing annotation
a) These rules should be read in conj uncti on with 11.1.3.
b) There are constrai nts on the way i n which the impl ementations of b_tr anspor t and nb_transpor t are
permi tted to modif y the ti me argument t such that the eff ective local time sc_time_stamp() + t i s
non-decreasing between function cal l and return (see 11.1.3.1).
c) For successive call s to and returns f rom nb_transpor t through a given socket for a given transaction,
the sequence of ef fective l ocal ti mes shall be non-decreasi ng. The eff ective l ocal ti me is gi ven by the
expression sc_time_stamp() + t, where t is the ti me argument to nb_transpor t. For thi s purpose,
both cal ls to and returns f rom the function shall be considered as part of a single sequence. Thi s
appl ies on the f orward and backward paths ali ke. The intent i s that ti me shoul d not run backward for
a gi ven transacti on.
d) The preceding rul e al so appl ies between the call to and the return f rom b_tr anspor t. Again, see
11.1.3.1.
e) Moreover, f or a gi ven transacti on obj ect, as requests are propagated f rom i nitiator toward target and
responses are propagated f rom target back toward i nitiator, the sequence of ef fecti ve local ti mes
given by each successive transport method cal l and return shall be non-decreasi ng. Request
propagation i n thi s sense includes call s to b_tr anspor t and the BEGIN_REQ phase. Response
propagation includes returns from b_tr anspor t, the BEGI N_RESP phase, and
TLM_COMPLETED.
f ) The ef fecti ve l ocal time may be i ncreased by increasing the val ue of the timing annotation (the ti me
argument), by advanci ng SystemC si mulation time (b_tr anspor t onl y), or both.
g) For di fferent transaction objects, there is no obli gation that the ef f ective l ocal times of call s to
b_tr anspor t and nb_transpor t shal l be non-decreasing. Nonetheless, each i nitiator process is
general ly recommended to cal l b_tr anspor t and/or nb_transpor t i n non-decreasi ng ef f ecti ve local
ti me order. Otherwise, downstream components would i nf er that the out-of-order transactions had
ori ginated from separate ini ti ators and would be f ree to choose the order in whi ch those parti cul ar
transactions were executed. However, transacti ons wi th out-of-order eff ective local times may arise
wherever streams of transactions from di ff erent loosel y-timed initiators converge.
h) For a given socket, an i niti ator i s al lowed to pass the same transacti on object at di ff erent ti mes
through the bl ocki ng and non-blocking transport interfaces, the direct memory interface, and the
debug transport i nterf ace. Al so, an i ni ti ator i s permi tted to re-use the same transacti on object for
di fferent transaction instances, al l subj ect to the memory management rul es of the generic payload
(see 14.5).
15.2.8 Base protocol rules concerning b_transport
a) b_tr anspor t calls are re-entrant. The i mplementati on of b_tr anspor t can cal l wait, and meanwhil e
another call to b_tr anspor t can be made for a dif ferent transacti on object from a di ff erent initiator
wi th no constraint on the ti ming annotation.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


515
Copyright 2012 IEEE. All rights reserved.
b) I n the case that there are mul ti pl e processes within the same initiator module, each process shall be
regarded as bei ng a separate ini tiator with respect to the transaction ordering rul es. Specif ically,
there are no constrai nts on the ordering of b_tr anspor t call s made f rom dif ferent threads i n the
same module, regardless of whether those call s are made through the same ini ti ator socket or
through dif ferent sockets.
c) An i nterconnect or target can always deduce that multi ple concurrent b_tr anspor t call s come from
dif ferent ini ti ator threads and from a dif ferent process to any concurrent nb_tr ansport_fw call s, and
theref ore that there are no constraints on the mutual order of those call s. With b_tr anspor t, one
request i s al lowed to overtake another.
d) I t is f orbi dden to make a re-entrant call to b_tr ansport for the same transaction object through the
same socket.
Exampl e:
The f ollowi ng pseudo-code f ragments show a re-entrant b_transport call :
// Two initiator thread processes
void thread1()
{
socket->b_transport( T1, sc_ti me(100, SC_NS) );
}
void thread2()
{
wait( 10, SC_NS);
socket->b_transport( T2, sc_ti me(50, SC_NS) ); // T2 overtakes T1
}
// Impl ementation of b_transport i n the target
void b_transport( TRANS& trans, sc_ti me& t )
{
wait( t );
execute( trans ); // T1 executed at 100ns, T2 executed at 60ns
t = SC_ZERO_TIME;
}
15.2.9 Base protocol rules concerning request and response ordering
The intent of the foll owing rules is to ensure that when an ini ti ator sends a series of pipeli ned requests to a
parti cul ar target, those requests wil l be executed at the target in the same order as they were sent from the
ini ti ator. Because the generi c payl oad transacti on stores nei ther the identi ty of the initiator nor the i dentity of
the target, the i nitiator can onl y be i nf erred from the identity of the incoming socket, and the target can onl y
be i nf erred from the values of the address and command attributes. The execution order of requests sent to
non-overlapping addresses i s not guaranteed.
a) The base protocol permits incoming requests or responses arri vi ng through di ff erent sockets to be
mutuall y delayed, interleaved, or executed in any order. For example, an interconnect component
may assi gn a hi gher pri ority to requests arriving through a parti cular target socket or havi ng a
parti cul ar data l ength, all owing them to overtake lower priori ty requests. As another exampl e, an
interconnect component may re-order responses arrivi ng back through dif ferent i niti ator sockets to
match the order in which the corresponding requests were ori ginall y received.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


516
Copyright 2012 IEEE. All rights reserved.
b) Request routing shall be determi nisti c and shall depend onl y on the address and command attri butes
of the transaction object. (These are the only attributes common to the transport, DMI, and debug
transport i nterf aces.) The address map shall not be modif ied whil e there are transacti ons in progress.
c) I f an initiator or i nterconnect component sends multipl e concurrent requests with overlapping
addresses on the f orward path, those requests shal l be routed through the same initiator socket.
Mul ti pl e concur rent requests means requests f or whi ch the correspondi ng responses have not yet
been received from the target. Over l appi ng addresses means that at l east one byte in the data arrays
of the transacti on objects shares the same address. Read and wri te requests to the same address may
be routed through dif ferent sockets provided they are not concurrent.
d) I f an interconnect component (or a target) recei ves multiple concurrent requests wi th overlappi ng
addresses through the same target socket by means of incoming cal ls to nb_tr ansport_fw, those
requests shal l be sent forward (or executed, respectively) in the same order as they were recei ved.
The same order means the same interface method cal l order. (Note that i f the i nterf ace method cal l
order and the effecti ve local time order of a set of transactions were to diff er, any component
receiving those transacti ons woul d be permitted to execute them i n any order, regardl ess of the
address. Also note that thi s rule holds even if the requests i n questi on origi nate from dif ferent
ini ti ators.)
e) Note that the precedi ng rul e does not apply f or incoming b_tr ansport call s, for whi ch there are no
constraints on the order of multiple concurrent requests. On the other hand, if i ncomi ng
nb_tr anspor t_fw call s are converted to outgoi ng b_tr anspor t call s, the b_tr anspor t call s must be
seriali zed to enforce the ordering rul es of the nb_transpor t cal ls.
f ) On the other hand, an i nterconnect component or target i s permitted to re-order mul ti pl e concurrent
requests that were received through di fferent target sockets, or are sent through di ff erent initiator
sockets, or whose addresses do not overlap, or for i ncomi ng b_tr anspor t cal ls.
g) Responses may be re-ordered. There is no guarantee that responses wil l arri ve back at an initiator in
the same order as the correspondi ng requests were sent.
h) Note that it woul d be technicall y possibl e with the base protocol to use an i gnorabl e extension that
all owed an interconnect component to re-order mul tipl e concurrent requests, in whi ch case the
ini ti ator that added the extensi on must be able to tol erate out-of-order executi on at the target. On the
other hand, an extensi on that forced responses to arrive back i n the same order as requests were sent
would not be an ignorable extension and, hence, would not be permi tted by the base protocol.
15.2.10 Base protocol rules for switching between b_transport and nb_transport
a) Each thread withi n an initiator or an i nterconnect component is permi tted to swi tch between call ing
b_tr anspor t and nb_tr anspor t_fw for dif f erent transacti on objects. The intent is to permit an
ini ti ator to make occasional switches between the loosel y-ti med and approximatel y-ti med coding
styles. An i niti ator that i nterl eaves calls to b_tr anspor t and nb_tr anspor t_fw should have low
expectati ons with regard to timi ng accuracy.
b) Every i nterconnect component and target i s obliged to support both the bl ocking and non-bl ocki ng
transport interfaces, and to mai ntain any i nternal state inf ormati on such that it is accessible from
both interfaces. Thi s appl ies to incoming interface method cal ls recei ved through the same socket or
through dif ferent sockets.
c) A thread wi thin an initiator or an interconnect component shal l not call both b_tr anspor t and
nb_tr anspor t_fw f or the same transacti on i nstance. Note that a thread may cal l both b_tr anspor t
and nb_tr anspor t_fw for the same transacti on obj ect provided that object represents a di ff erent
transaction instance on each occasion.
d) I t is recommended that a thread wi thi n an initiator or interconnect component should not cal l
b_tr anspor t i f there is stil l a transacti on i n progress from a previous nb_tr anspor t_fw call f rom
that same thread, that i s, when there i s a previ ous transaction with a non-zero reference count.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


517
Copyright 2012 IEEE. All rights reserved.
Otherwise, a downstream component could wrongly deduce that the two transacti ons had come from
separate ini ti ators.
e) The conveni ence socket simple_tar get_socket provides an example of how a base protocol target
can support both the bl ocking and the non-bl ocking transport interfaces whil e onl y being requi red to
impl ement one of b_tr anspor t and nb_tr ansport_fw (see 16.1.2).
15.2.11 Other base protocol rules
a) A given transaction obj ect shall not be sent through mul tipl e paral lel sockets or along multiple
parall el paths si multaneously. Each transaction instance shall take a uni que wel l-def ined path
through a set of components and sockets that shal l remai n fi xed f or the li feti me of the transaction
instance and is common to the transport, direct memory, and debug transport interf aces. Of course,
dif ferent transacti ons sent through a gi ven socket may take dif ferent paths; that i s, they may be
routed dif ferentl y. Also, note that a component may choose dynami call y whether to act as an
interconnect component or as a target.
b) An upstream component should not know and shoul d not need to know whether i t is connected to an
interconnect component or directly to a target. Simil arly, a downstream component should not know
and should not need to know whether it i s connected to an i nterconnect component or directly to an
ini ti ator.
c) For a write transacti on (TLM_WRI TE_COMMAND), a response status of TLM_OK_RESPONSE
shal l i ndi cate that the wri te command has completed successfull y at the target. The target is obl iged
to set the response status bef ore returning f rom b_tr anspor t, before sending BEGI N_RESP along
the backward or return path, or bef ore returning TLM_COMPLETED. I n other words, an
interconnect component is not permitted to signal the compl etion of a write transacti on wi thout
havi ng had confi rmation of successful compl etion f rom the target. The intent of thi s rule i s to
guarantee the coherency of the storage withi n the target si mul ation model .
d) For a read transaction (TLM_READ_COMMAND), a response status of TLM_OK_RESPONSE
shal l indicate that the read command has compl eted and the generi c payload data array has been
modif ied by the target. The target is obli ged to set the response status bef ore returning f rom
b_tr anspor t, bef ore sendi ng BEGI N_RESP along the backward or return path, or bef ore returni ng
TLM_COMPLETED.
15.2.12 Summary of base protocol transaction ordering rules
Tabl e 58 gi ves a summary of the transacti on orderi ng rul es f or the base protocol . For a f ul l descri ption of the
rul es, ref er to the cl auses above.
The base protocol ordering rul es are a union of the rules f rom three categori es: rules of the core transport
interfaces concerni ng timi ng annotation, rules speci fi c to the base protocol concerning causal ity and phases,
and rul es speci fi c to the base protocol that ensure that pi pel ined requests are executed at the target in the
order expected by the ini ti ator.
15.2.13 Guidelines for creating base-protocol-compliant components
This clause contains a set of guidel ines for creati ng base protocol components. This is j ust a brief
restatement of some rules presented more ful ly elsewhere i n thi s document, and i s provided f or conveni ence.
15.2.13.1 Guidelines for creating a base protocol initiator
a) I nstanti ate one i ni ti ator socket of class tlm_initiator _socket (or a deri ved cl ass) for each connecti on
to a memory-mapped bus.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


518
Copyright 2012 IEEE. All rights reserved.
b) Al low the tlm_initiator _socket to take the def aul t val ue tlm_base_protocol_types for the templ ate
TYPES argument.
c) I mplement the methods nb_tr ansport_bw and invalidate_direct_mem_ptr . (An ini tiator can
avoi d the need to impl ement these methods expl icitly by i nstanti ati ng the conveni ence socket
simple_initiator _socket.)
d) Set every attri bute of each generic payload transacti on object bef ore passing i t as an argument to
b_tr anspor t or nb_tr ansport_fw, rememberi ng i n particular to reset the response status and DMI
hint attributes before the call . (The byte enabl e l ength attribute need not be set in the case where the
byte enable poi nter attri bute i s 0, and extensi ons need not be used.)
e) When using the generic payload extension mechanism, ensure that any extensi ons are i gnorabl e by
the target and any interconnect component.
f ) Obey the base protocol rul es concerning phase sequencing, f low control, ti ming annotati on, and
transaction orderi ng.
g) On completion of the transacti on (or af ter receivi ng BEGI N_RESP), check the value of the response
status attribute.
Table 58Base protocol transaction ordering rules
Circumstance Or der ing r ule
Ef fecti ve l ocal time order di f ferent f rom i nterf ace method cal l
order
Reci pi ent may execute or route transacti ons i n
any order. Takes precedence over all other rul es
Successi ve transport method cal l s and returns f or the same
transacti on through the same socket
Ef f ecti ve l ocal ti me order shal l be non-
decreasi ng
Successi ve transport method cal l s f rom the same i niti ator process Ef f ecti ve l ocal ti me order i s recommended to be
non-decreasi ng
Successi ve transport method cal l s f rom the same i ni ti ator process Recommended not to cal l b_transport i f
previ ous nb_transport transacti on i s sti l l al i ve
Successi ve transport method cal l s f or di f f erent transacti ons
through the same socket
No obli gati on on ef fecti ve l ocal ti me order, but
recommended to be non-decreasi ng i f i ncomi ng
transacti on stream was non-decreasi ng
Wi th nb_transport onl y, two requests or two responses
outstandi ng through the same socket
Forbi dden
Transacti ons i ncomi ng through di f f erent sockets No obl igati ons on the order i n whi ch they are
executed or routed on
Mul ti pl e concurrent requests wi th overl appi ng addresses I f routed forward, shal l be sent through the
same socket
Multi pl e concurrent requests wi th overl appi ng addresses
i ncomi ng through the same socket usi ng nb_transport
Shal l be executed or routed f orward i n the same
order as they were recei ved
Multi pl e concurrent requests i ncomi ng usi ng b_transport No obl i gati ons on the order i n whi ch they are
executed or routed forward
Mul ti pl e concurrent responses No obli gati ons on the order i n whi ch they are
executed or routed back
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


519
Copyright 2012 IEEE. All rights reserved.
15.2.13.2 Guidelines for creating an initiator that calls nb_transport
a) Before passing a transacti on as an argument to nb_tr ansport_fw, set a memory manager for the
transaction object and cal l the acquire method of the transaction. Call the release method when the
transaction is compl ete.
b) When cal ling nb_tr ansport_fw, set the phase argument to BEGI N_REQ or END_RESP according
to state of the transaction. Do not send BEGI N_REQ before having received (or i nf erred) the
END_REQ f rom the previous transacti on.
c) When making a series of cal ls to nb_tr ansport_fw f or a given transaction, ensure that the eff ecti ve
local ti mes (si mulati on time + timi ng annotation) form a non-decreasing sequence of val ues.
d) Respond appropri atel y to the i ncomi ng phase values END_REQ and BEGIN_RESP whether
received on the backward path (a call to nb_tr ansport_bw), the return path (TLM_UPDATED
returned f rom nb_tr ansport_fw), or impl icitly (f or exampl e, TLM_COMPLETED returned f rom
nb_tr anspor t_fw). Incoming phase values of BEGIN_REQ and END_RESP would be il legal .
Treat all other incoming phase values as being ignorable.
15.2.13.3 Guidelines for creating a base protocol target
a) I nstanti ate one target socket of cl ass tlm_tar get_socket (or a derived class) for each connection to a
memory-mapped bus.
b) Al low the tlm_tar get_socket to take the default value tlm_base_protocol_types f or the templ ate
TYPES argument.
c) I mplement the methods b_tr anspor t, nb_tr ansport_fw, get_dir ect_mem_ptr, and
transpor t_dbg. (A target can avoi d the need to i mplement every method expli citl y by usi ng the
convenience socket simple_tar get_socket.)
d) I n the i mplementati ons of the methods b_tr anspor t and nb_tr anspor t_fw, i nspect and act on the
val ue of every attri bute of the generi c payl oad wi th the exception of the response status, the DMI
hint, and any extensi ons. Rather than impl ementing the ful l f uncti onali ty of the generi c payload, a
target may choose to respond to a gi ven attri bute by generati ng an error response. Set the value of
the response status attribute to i ndi cate the success or fail ure of the transaction.
e) Obey the base protocol rul es concerning phase sequencing, f low control, ti ming annotati on, and
transaction orderi ng.
f ) In the implementation of get_dir ect_mem_ptr , either return the val ue false, or i nspect and act on
the val ues of the command and address attributes of the generic payload and set the return val ue and
all the attributes of the DMI descriptor appropri ately (cl ass tlm_dmi).
g) I n the i mplementation of transpor t_dbg, ei ther return the val ue 0, or inspect and act on the values
of the command, address, data l ength, and data pointer attri butes of the generic payload.
h) For each i nterf ace, the target may inspect and act on any i gnorable extensi ons i n the generi c
payl oad, but is not obl iged to do so.
15.2.13.4 Guidelines for creating a target that calls nb_transport
a) When cal ling nb_tr ansport_bw, set the phase argument to END_REQ or BEGI N_RESP according
to state of the transacti on. Do not send BEGI N_RESP before havi ng recei ved (or i nferred)
END_RESP from the previous transacti on.
b) When maki ng a series of call s to nb_tr anspor t_bw for a given transacti on, ensure that the eff ective
local ti mes (si mulati on time + timi ng annotation) form a non-decreasing sequence of val ues.
c) Respond appropriately to the incoming phase val ues BEGI N_REQ and END_RESP, whether
received on the f orward path (a call to nb_tr anspor t_fw), the return path (TLM_UPDATED
returned from nb_tr anspor t_bw), or impl icitly (f or example, TLM_COMPLETED returned f rom
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


520
Copyright 2012 IEEE. All rights reserved.
nb_tr anspor t_bw). I ncoming phase val ues of END_REQ and BEGIN_RESP woul d be i llegal.
Treat all other incoming phase values as being ignorable.
d) I n the impl ementation of nb_tr ansport_fw, when needing to keep a pointer or reference to a
transaction object beyond the return from the method, cal l the acquire method of the transaction.
Call the release method when the transaction object is fi nished with.
15.2.13.5 Guidelines for creating a base protocol interconnect component
a) I nstanti ate one ini ti ator or target socket of class tlm_initiator _socket or tlm_tar get_socket (or
deri ved cl asses) f or each connecti on to a memory-mapped bus.
b) Al low each socket to take the default value tlm_base_protocol_types f or the template TYPES
argument.
c) I mplement the methods nb_tr anspor t_bw and invalidate_direct_mem_ptr for each ini tiator
socket, and the methods b_tr anspor t, nb_tr anspor t_fw, get_dir ect_mem_ptr, and
transpor t_dbg f or each target socket. (The need to i mplement every method expl icitly can be
avoi ded by using the conveni ence sockets.)
d) Pass on i ncomi ng interface method cal ls as appropri ate on both the f orward and backward paths,
honoring the request and response excl usi on rul es, the transaction orderi ng rul es, and the rule that no
f urther call s are all owed f ol lowi ng TLM_COMPLETED. Do not pass on ignorabl e phases. The
impl ementations of the get_dir ect_mem_ptr and transpor t_dbg methods may return the values
false and 0, respectively, wi thout forwarding the transacti on object.
e) I n the implementati on of the transport i nterf aces, the onl y generic payl oad attributes modi fi abl e by
an i nterconnect component are the address, DMI hint, and extensi ons. Do not modi fy any other
attri butes. A component needi ng to modi fy any other attributes should construct a new transacti on
object, and thereby become an initiator in its own ri ght.
f ) Decode the generic payl oad address attri bute on the forward path and modif y the address attribute if
necessary according to the location of the target in the system memory map. Thi s appli es to the
transport, di rect memory, and debug transport i nterf aces.
g) In the i mplementati on of the transport i nterf aces, obey the base protocol rules concerning phase
sequenci ng, fl ow control, timi ng annotation, and transaction ordering.
h) I n the i mplementati on of get_dir ect_mem_ptr, do not modif y the DMI descri ptor attributes on the
f orward path. Do modif y the DMI pointer, DMI start address and end address, and DMI access
attri butes appropriately on the return path.
i ) I n the impl ementation of invalidate_direct_mem_ptr , modi fy the address range arguments before
passing the call al ong the backward path.
j ) I n the i mpl ementation of nb_tr ansport_fw, when needing to keep a pointer or reference to a
transaction object beyond the return f rom the f unction, cal l the acquire method of the transaction.
Call the release method when the transaction object is fi nished with.
k) For each i nterf ace, the i nterconnect component may i nspect and act on any ignorable extensions i n
the generi c payload but i s not obli ged to do so. If the transaction needs to be extended f urther, make
sure any extensi ons are i gnorabl e by the other components. Honor the generi c payl oad memory
management rul es f or extensions.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


521
Copyright 2012 IEEE. All rights reserved.
16. TLM-2.0 utilities
The uti li ties compri se a set of classes that are provided for convenience and to hel p ensure a consistent
codi ng style. The uti li ti es do not belong to the i nteroperabil ity layer, so use of the uti li ti es is not a
requirement for i nteroperabi li ty.
16.1 Convenience sockets
16.1.1 Introduction
Therei safamil y of conveniencesockets, each socket i mplementi ng some additional functi onal ity to make
component model s easier to write. The convenience sockets are deri ved from the classes
tl m_i niti ator _socket and tlm_tar get_socket. They are not part of the TLM-2.0 interoperabil ity layer but
areto befound in thenamespacetl m_util s.
16.1.1.1 Summary of standard and convenience socket types
Theconveniencesockets aresummari zed in Tabl e59.
Register cal lbacks? Thesocket provi desmethodsto regi ster cal lbacksfor i ncomi nginterfacemethod call s,
rather than havi ngthesocket bebound to an object that i mplementsthecorresponding interfaces.
M ul ti -por ts? The socket class template provi des number-of-bindings and bi ndi ng poli cy template
argumentssuch that asingleini tiator socket can bebound to multipletarget socketsand vi ceversa.
b - nb conver sion? The target socket i s able to convert i ncomi ng cal ls to b_tr anspor t into
nb_tr ansport_fw cal ls, and vi ceversa. A '-' indi catesan initiator socket.
Tagged? Incomi ng interface method call s are tagged wi th an id to indicate thesocket through which they
arrived.
Table 59Socket types
Class
Register
callbacks?
M ulti-ports?
b / nb
conver sion?
T agged?
tlm_initiator_socket no yes - no
tlm_target_socket no yes no no
simple_initiator_socket yes no - no
simple_initiator_socket_tagged yes no - yes
simple_target_socket yes no yes no
simple_target_socket_tagged yes no yes yes
passthrough_target_socket yes no no no
passthrough_target_socket_tagged yes no no yes
multi_passthrough_initiator_socket yes yes - yes
multi_passthrough_target_socket yes yes no yes
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


522
Copyright 2012 IEEE. All rights reserved.
16.1.1.2 Permitted socket bindings
The bi ndi ngs permi tted between the standard and convenience socket types are summarized i n Tabl e 60.
Each bi nding i s of the f orm From( To) or From.bind( To ), where From and To are sockets of the given type.
Tabl e 60 is organi zed i nto f our quarters as f ol lows:
Table 60Permitted socket bindings
To
From
tl m-i ni t si mpl e-i ni t mul ti -i ni t tl m-targ si mpl e-targ multi -targ
tl m-i ni t 1 1 1 N:1
si mpl e-i ni t 1 1 1 N:1
mul ti -i ni t 1 1:M 1:M N:M
tl m-targ 1* 1* 1 1
si mpl e-targ 1* 1*
mul ti -targ 1
Hi erarchical chi l d-to-parent bi ndi ng I niti ator-to-target bi ndi ng
Reverse bi nding operators Hierarchi cal parent-to-chi l d bi ndi ng
Key
tl m-i ni t tlm_i ni tiator_socket
si mpl e-i ni t si mpl e_i ni ti ator_socket or passthrough_i ni ti ator_socket
multi -i ni t mul ti _passthrough_i ni ti ator_socket
tl m-targ tlm_target_socket
si mpl e-targ si mpl e_target_socket or si mpl e_target_socket_tagged or
passthrough_target_socket or passthrough_target_socket_tagged
multi -targ mul ti _passthrough_target_socket
1* The bi ndi ng i s f rom i ni ti ti ator to target, despi te the method cal l bei ng
i n the di recti on target.bi nd(i ni ti ator)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


523
Copyright 2012 IEEE. All rights reserved.
16.1.2 Simple sockets
16.1.2.1 Introduction
The si mpl e sockets are so-cal led because they are intended to be si mple to use. They are derived from the
interoperabi li ty l ayer sockets tlm_initiator _socket and tlm_tar get_socket, so can be bound directl y to
sockets of those types.
I nstead of havi ng to bi nd a socket to an obj ect that i mplements the correspondi ng i nterf ace, each si mple
socket provi des methods f or regi steri ng call back methods. Those call backs are in turn cal led whenever an
incoming i nterf ace method cal l arrives. Cal lback methods may be registered f or each of the i nterfaces
supported by the socket.
The user of a simpl e socket may regi ster a call back for every interf ace method but i s not obliged to do so. In
parti cul ar, for the si mple target socket, the user need onl y regi ster one of b_tr anspor t and
nb_tr ansport_fw, in whi ch case i ncoming calls to the unregi stered method wil l be converted automati cal ly
to call s to the registered method. Thi s conversi on process is non-trivial , and is dependent on the rules of the
base protocol bei ng respected by the ini ti ator and target. Hence, although the class templ ate
simple_tar get_socket takes the protocol type as a template parameter, there exists a dependency between
thi s cl ass and the base protocol that i s onl y exposed i f the appli cation makes use of the conversion between
blocking and non-bl ocking transport call s. Specif ically, cl ass simple_tar get_socket uses the val ues of type
tlm_phase_enum. An appl ication requi ri ng such a conversi on for a protocol other than the base protocol
would be obli ged to create a new convenience socket, possibl y deri ved f rom simple_target_socket. The
passthr ough_tar get_socket is a variant of the simple_tar get_socket that does not support conversion
between blocking and non-bl ocki ng cal ls.
16.1.2.2 Class definition
namespace tl m_util s {
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class simple_initiator _socket : publi c tl m::tlm_i ni ti ator_socket<BUSWIDTH, TYPES>
{
public:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
simple_initiator _socket();
expl icit simple_initiator _socket( const char* n );
void register _nb_tr anspor t_bw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(transaction_type&, phase_type&, sc_core::sc_ti me& ));
void register _invalidate_direct_mem_ptr (
MODULE* mod,
void (MODULE::* cb)(sc_dt::ui nt64, sc_dt::ui nt64));
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


524
Copyright 2012 IEEE. All rights reserved.
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class simple_target_socket : publi c tlm::tlm_target_socket<BUSWIDTH, TYPES>
{
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
simple_tar get_socket();
expl icit simple_target_socket( const char* n );
tl m::tlm_bw_transport_i f<TYPES> * oper ator ->();
void register _nb_transpor t_fw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(transaction_type&, phase_type&, sc_core::sc_ti me& ));
void register _b_tr anspor t(
MODULE* mod,
void (MODULE::* cb)(transacti on_type&, sc_core::sc_ti me& ));
void register _tr anspor t_dbg(
MODULE* mod,
unsi gned int (MODULE::* cb)(transaction_type&));
void register _get_direct_mem_ptr (
MODULE* mod,
bool (MODULE::* cb)(transaction_type&, tlm::tl m_dmi&));
} ;
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class passthr ough_tar get_socket : publ ic tl m::tlm_target_socket<BUSWI DTH, TYPES>
{
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
passthr ough_tar get_socket();
expl icit passthr ough_tar get_socket( const char* n );
void register _nb_transpor t_fw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(transaction_type&, phase_type&, sc_core::sc_ti me& ));
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


525
Copyright 2012 IEEE. All rights reserved.
void register _b_tr anspor t(
MODULE* mod,
void (MODULE::* cb)(transacti on_type&, sc_core::sc_time&));
void register _tr anspor t_dbg(
MODULE* mod,
unsi gned int (MODULE::* cb)(transaction_type&));
void register _get_direct_mem_ptr (
MODULE* mod,
bool (MODULE::* cb)(transaction_type&, tlm::tl m_dmi&));
} ;
} // namespace tl m_uti ls
16.1.2.3 Header file
The class defi ni ti ons for the simpl e sockets shall be in the header fi les tlm_utils/simple_initiator _socket.h,
tlm_utils/simple_tar get_socket.h, and tlm_utils/passthr ough_tar get_socket.h.
16.1.2.4 Rules
a) Each constructor shal l cal l the constructor of the correspondi ng base class passi ng through thechar *
argument, i f there i s one. I n the case of the def ault constructors, the char * argument of the base class
constructor shal l be set to sc_gen_unique_name ( "si mple_initiator_socket" ), sc_gen_unique_name
( "simpl e_target_socket" ), or sc_gen_uni que_name ( "passthrough_target_socket" ), respectively.
b) A simple_initiator _socket can be bound to a simple_target_socket or a
passthr ough_tar get_socket by cal li ng the bind method or oper ator () of ei ther socket, with
precisely the same ef fect. I n either case, the f orward path li es in the directi on f rom the i ni ti ator
socket to the target socket.
c) A simple_initiator _socket can be bound to a tlm_tar get_socket, and a tlm_initiator _socket can
be bound to a simple_target_socket or to a passthr ough_tar get_socket.
d) A simple_initiator _socket, simple_tar get_socket or passthr ough_tar get_socket can only
impl ement i ncomi ng i nterf ace method cal ls by registering cal lbacks, not by being bound
hierarchi cal ly to another socket on a chi ld module. On the other hand, a simple_initiator _socket of
a chi ld module can be bound hi erarchical ly to a tlm_initiator _socket of a parent modul e, and a
tlm_tar get_socket of a parent module can be bound hierarchi cal ly to a simple_target_socket or
passthr ough_tar get_socket of a chi ld modul e.
e) A target is not obl iged to regi ster a b_tr anspor t cal lback wi th a simpl e target socket provi ded it has
regi stered an nb_tr ansport_fw cal lback, in whi ch case an incoming b_tr anspor t cal l wi ll
automati call y cause the target to call the method regi stered for nb_tr ansport_fw. I n this case, the
method registered f or nb_tr ansport_fw shal l i mplement with the rul es of the base protocol (see
16.1.2.5).
f ) A target is not obli ged to register an nb_tr ansport_fw call back with a simpl e target socket provided
it has registered a b_tr anspor t cal lback, in which case an i ncomi ng nb_tr ansport_fw cal l wil l
automati call y cause the target to call the method regi stered f or b_tr anspor t and subsequently to call
nb_tr anspor t_bw on the backward path.
g) If a target does not regi ster either a b_tr anspor t or an nb_tr ansport_fw cal lback with a simpl e
target socket, thi s will resul t i n a run-time error i f and onl y i f the corresponding method is call ed.
h) A target should regi ster b_tr anspor t and nb_tr ansport_fw cal lbacks wi th a passthrough target
socket. Not doing so wi ll result in a run-time error if and only i f the corresponding method i s call ed.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


526
Copyright 2012 IEEE. All rights reserved.
i ) A target is not obliged to register a tr anspor t_dbg cal lback wi th a si mple target socket or a
passthrough target socket, in which case an i ncomi ng transpor t_dbg cal l shall return with a val ue
of 0.
j ) A target is not obl iged to regi ster a get_direct_mem_ptr cal lback wi th a si mple target socket or a
passthrough target socket, i n which case an i ncoming get_dir ect_mem_ptr cal l shall return wi th a
val ue of false.
k) An i nitiator should register an nb_tr anspor t_bw call back wi th a si mple i ni ti ator socket. Not doi ng
so wi ll resul t i n a run-time error i f and only if the nb_tr anspor t_bw method is call ed.
l ) An i nitiator is not obl iged to register an invalidate_direct_mem_ptr call back wi th a si mple i ni ti ator
socket, in which case an incoming invalidate_direct_mem_ptr cal l shal l be i gnored.
16.1.2.5 Simple target socket b/nb conversion
a) I n the case that a b_tr anspor t or nb_tr ansport_fw method is cal led through a socket of cl ass
simple_target_socket but no correspondi ng cal lback is regi stered, the si mple target socket wi ll act
as an adapter between the two i nterf aces. I n thi s case, and i n no other case, the impl ementation of
simple_target_socket shal l have an expl icit dependency on the values of type tlm_phase_enum.
b) When the si mple target socket acts as an adapter, it shall honor the rules of the base protocol both
f rom the point of view of the i ni ti ator and from the poi nt of vi ew of the impl ementation of the
b_tr anspor t or nb_tr ansport_fw methods i n the target (see 15.2).
c) The socket shal l pass through the given transacti on obj ect without modif ication and shall not
construct a new transaction obj ect.
d) I n the case that only the nb_tr ansport_fw callback has been regi stered by the target, the i nitiator is
not permi tted to cal l nb_tr ansport_fw whil e there i s an earli er b_tr anspor t cal l from the initiator
sti ll i n progress. Thi s i s a li mitati on of the current impl ementation of the si mple target socket.
Figure 34Simple target socket nb/b adapter
Simulation time= 100ns
I nitiator Socket Tar get
Simulation time= 105ns
Simulation time= 115ns
Cal l
Retur n
TLM_ACCEPTED
TLM_COMPLETED
nb_transport_fw(t,BEGI N_REQ,5ns)
nb_transport_bw(t,BEGIN_RESP,0ns) Cal l
Retur n
Cal l
Retur n
b_transport(t,0ns)
b_transport(t,10ns)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


527
Copyright 2012 IEEE. All rights reserved.
e) Figure 34 shows the case where an ini ti ator call s nb_tr ansport_fw, but the target onl y registers a
b_tr anspor t call back wi th the simpl e target socket. The i niti ator sends BEGIN_REQ, to whi ch the
socket returns TLM_ACCEPTED. The socket then calls b_tr anspor t, and on return sends
BEGI N_RESP back to the i ni ti ator, to which the i ni ti ator returns TLM_COMPLETED. Si nce i t i s
not permissi ble i n SystemC to cal l a blocki ng method directly f rom a non-blocki ng method, the
socket i s obli ged to call b_tr anspor t f rom a separate internal thread process, not directl y from
nb_tr anspor t_fw.
f ) Figure 34 shows j ust one possibl e scenario. On the fi nal transi tion, the i nitiator coul d have returned
TLM_ACCEPTED, in which case the socket would expect to receive a subsequent END_RESP
f rom the ini ti ator. Also, the target coul d have call ed wait from within b_tr anspor t.
g) Figure 35 shows the case where an i nitiator cal ls b_tr anspor t, but the target onl y registers an
nb_tr anspor t_fw call back with the simpl e target socket. The initiator cal ls b_tr anspor t, then the
socket and the target handshake using nb_transpor t and obeyi ng the rul es of the base protocol . The
target may or may not send the END_REQ phase; i t may j ump straight to the BEGI N_RESP phase.
The socket returns TLM_COMPLETED from the cal l to nb_tr anspor t_bw f or the BEGIN_RESP
phase.
Figure 35Simple target socket b/nb adapter
Exampl e:
#include "tlm.h"
#include "tlm_util s/si mple_initiator_socket.h" // Header fi les f rom util iti es
#include "tlm_util s/si mple_target_socket.h"
struct I nitiator: sc_module
{
tlm_utils::simple_initiator _socket<I ni ti ator, 32, tlm::tlm_base_protocol_types> socket;
Simulation time = 100ns
I nitiator Socket Tar get
Simulation time= 110ns
Simulation time = 120ns
Cal l
b_transport(t,10ns)
b_transport(t,0ns)
Cal l
Retur n
nb_transport_fw(t,BEGIN_REQ, 0ns)
TLM_ACCEPTED
Simulation time = 130ns
Cal l
Retur n
nb_transport_bw(t,END_REQ, 0ns)
TLM_ACCEPTED
Cal l
Retur n
nb_transport_bw(t,BEGIN_RESP,0ns)
TLM_COMPLETED
Retur n
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


528
Copyright 2012 IEEE. All rights reserved.
SC_CTOR(Initiator)
: socket("socket") // Construct and name simpl e socket
{ // Regi ster cal lbacks with si mple socket
socket.register_nb_transport_bw( this, &I ni ti ator::nb_transport_bw );
socket.register_i nvali date_di rect_mem_ptr( this, &Ini tiator::invali date_direct_mem_ptr );
}
virtual tlm::tlm_sync_enum nb_transport_bw(
tl m::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) {
return tl m::TLM_COMPLETED; // Dummy impl ementation
}
virtual void inval idate_direct_mem_ptr(sc_dt::uint64 start_range, sc_dt::uint64 end_range)
{ } // Dummy impl ementation
} ;
struct Target: sc_module // Target component
{
tlm_utils::simple_target_socket<Target, 32, tlm::tlm_base_protocol_types> socket;
SC_CTOR(Target)
: socket("socket") // Construct and name simpl e socket
{ // Regi ster cal lbacks with si mple socket
socket.register_nb_transport_f w( this, &Target::nb_transport_fw );
socket.register_b_transport( thi s, &Target::b_transport );
socket.register_get_direct_mem_ptr( thi s, &Target::get_direct_mem_ptr );
socket.register_transport_dbg( thi s, &Target::transport_dbg );
}
virtual void b_transport( tlm::tlm_generic_payload& trans, sc_ti me& del ay )
{ } // Dummy impl ementation
virtual tl m::tlm_sync_enum nb_transport_fw(
tl m::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) {
return tl m::TLM_ACCEPTED; // Dummy impl ementation
}
virtual bool get_di rect_mem_ptr( tl m::tl m_generi c_payload& trans, tlm::tlm_dmi & dmi_data)
{ return fal se; } // Dummy impl ementation
virtual unsi gned int transport_dbg(tl m::tl m_generi c_payl oad& r)
{ return 0; } // Dummy impl ementation
} ;
SC_MODULE(Top)
{
Ini ti ator * initiator;
Target * target;
SC_CTOR(Top) {
ini ti ator = new I nitiator("ini ti ator");
target = new Target("target");
ini ti ator->socket.bi nd( target->socket ); // Bind ini tiator socket to target socket
}
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


529
Copyright 2012 IEEE. All rights reserved.
16.1.3 Tagged simple sockets
16.1.3.1 Introduction
The tagged simpl e sockets are a variati on on the simple sockets that tag i ncomi ng interface method call s
wi th an integer id that allows the call back to i dentify through whi ch socket the i ncomi ng cal l arrived. This is
usef ul in the case where the same cal lback method is regi stered with multiple i ni ti ator sockets or multi ple
target sockets. The i d i s specif ied when the call back i s registered, and gets inserted as an extra fi rst argument
to the cal lback method.
16.1.3.2 Header file
The class def initions f or the tagged simpl e sockets shal l be in the same header f iles as the corresponding
simpl e sockets, that i s tlm_utils/simple_initiator _socket.h, tlm_utils/simple_target_socket.h, and
tlm_utils/passthr ough_tar get_socket.h.
16.1.3.3 Class definition
namespace tl m_util s {
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class simple_initiator _socket_tagged : publi c tlm::tlm_i niti ator_socket<BUSWIDTH, TYPES>
{
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
simple_initiator _socket_tagged();
expl icit simple_initiator _socket_tagged( const char* n );
void register _nb_tr anspor t_bw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(i nt, transaction_type& , phase_type&, sc_core::sc_time&),
int id);
void register _invalidate_direct_mem_ptr (
MODULE* mod,
void (MODULE::* cb)(i nt, sc_dt::uint64, sc_dt::uint64),
int id);
} ;
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class simple_target_socket_tagged : publi c tlm::tlm_target_socket<BUSWI DTH, TYPES>
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


530
Copyright 2012 IEEE. All rights reserved.
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
typedef tl m::tl m_fw_transport_if <TYPES> f w_i nterf ace_type;
typedef tl m::tl m_bw_transport_i f<TYPES> bw_interface_type;
typedef tl m::tl m_target_socket<BUSWIDTH, TYPES> base_type;
simple_target_socket_tagged();
expl icit simple_target_socket_tagged( const char* n );
tl m::tlm_bw_transport_i f<TYPES> * oper ator ->();
void register _nb_transpor t_fw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(i nt id, transaction_type& , phase_type&, sc_core::sc_time&),
int id);
void register _b_tr anspor t(
MODULE* mod,
void (MODULE::* cb)(i nt id, transaction_type& , sc_core::sc_time&),
int id);
void register _tr anspor t_dbg(
MODULE* mod,
unsi gned int (MODULE::* cb)(int id, transacti on_type&),
int id);
void register _get_direct_mem_ptr (
MODULE* mod,
bool (MODULE::* cb)(i nt id, transaction_type&, tlm::tlm_dmi &),
int i d);
} ;
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tlm::tl m_base_protocol_types
>
class passthr ough_tar get_socket_tagged : publi c tlm::tlm_target_socket<BUSWI DTH, TYPES>
{
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
passthr ough_tar get_socket_tagged();
expl icit passthr ough_tar get_socket_tagged( const char* n );
void register _nb_transpor t_fw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(i nt id, transaction_type& , phase_type&, sc_core::sc_time&),
int id);
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


531
Copyright 2012 IEEE. All rights reserved.
void register _b_tr anspor t(
MODULE* mod,
void (MODULE::* cb)(i nt id, transaction_type& , sc_core::sc_time&),
int id);
void register _tr anspor t_dbg(
MODULE* mod,
unsi gned int (MODULE::* cb)(int id, transacti on_type&),
int id);
void register _get_direct_mem_ptr (
MODULE* mod,
bool (MODULE::* cb)(i nt id, transaction_type&, tlm::tlm_dmi &),
int id);
} ;
} // namespace tl m_uti ls
16.1.3.4 Rules
a) Each constructor shal l cal l the constructor of the correspondi ng base class passi ng through the char *
argument, i f there i s one. I n the case of the def ault constructors, the char * argument of the base class
constructor shall be set to sc_gen_unique_name ("si mple_ini tiator_socket_tagged"),
sc_gen_unique_name ("si mple_target_socket_tagged"), or sc_gen_unique_name
("passthrough_target_socket_tagged"), respectively.
b) Apart from the i nt i d tag, the tagged si mple sockets behave in the same way as the untagged simple
sockets.
c) A given call back method can be regi stered with mul ti ple sockets i nstances using diff erent tags. Thi s
is the purpose of the tagged sockets.
d) The int id tag is speci fi ed as the f inal argument of the methods used to register the cal lbacks. The
socket shall prepend this tag as the f irst argument of the corresponding cal lback method. Note that
the order of the id tag argument di ff ers between the registrati on method and the cal lback method.
See the exampl e below.
e) A tagged si mple socket i s not a multi-socket. A tagged simpl e socket cannot be bound to multipl e
sockets on other components (see 16.1.4).
Exampl e:
struct my_target: sc_module
{
tl m_uti ls::si mple_target_socket_tagged<my_target> socket1;
tl m_uti ls::si mple_target_socket_tagged<my_target> socket2;
SC_CTOR(my_target)
: socket1("socket1"), socket2("socket2")
{
socket1.register_b_transport(thi s, &my_target::b_transport, 1); // Registered wi th id = 1
socket2.register_b_transport(thi s, &my_target::b_transport, 2); // Registered wi th id = 2
}
void b_transport(int i d, Transacti on& trans, sc_time& del ay); // May be call ed wi th id = 1 or id = 2
...
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


532
Copyright 2012 IEEE. All rights reserved.
16.1.4 Multi-sockets
16.1.4.1 Introduction
The multi-sockets are a variation on the tagged si mple sockets that permi t a si ngl e socket to be bound to
mul tipl e sockets on other components. In contrast to the tagged simple sockets, whi ch i denti fy through
which socket an incoming call arri ves, a mul ti -socket cal lback i s able to i dentif y from whi ch socket on
another component an incoming interface method cal l arri ves, usi ng the multi-port index number as the tag.
Unli ke the other convenience sockets, the mul ti -sockets also support hi erarchical chil d-to-parent socket
binding on both the ini tiator and the target side.
16.1.4.2 Header file
The class defi nitions for the multi-sockets shall be i n the header f il es tlm_utils/
multi_passthrough_initiator _socket.h and tlm_utils/multi_passthrough_tar get_socket.h.
16.1.4.3 Class definition
namespace tl m_util s {
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tl m::tl m_base_protocol _types,
unsi gned int N=0,
sc_core::sc_port_poli cy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class multi_passthrough_initiator _socket : publi c mul ti _i ni t_base< BUSWI DTH, TYPES, N, POL>
{
publ ic:
typedef typename TYPES::tlm_payl oad_type transacti on_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
typedef multi_ini t_base<BUSWI DTH, TYPES, N, POL> base_type;
typedef typename base_type::base_target_socket_type base_target_socket_type;
multi_passthrough_initiator _socket();
multi_passthrough_initiator _socket(const char* name);
~multi_passthrough_initiator _socket();
void register _nb_tr anspor t_bw(
MODULE* mod,
sync_enum_type (MODULE::* cb)(i nt, transaction_type& , phase_type&, sc_core::sc_time&));
void register _invalidate_direct_mem_ptr (
MODULE* mod,
void (MODULE::* cb)(i nt, sc_dt::uint64, sc_dt::uint64));
// Overri de vi rtual f unctions of the tl m_ini ti ator_socket:
virtual tlm::tlm_bw_transport_i f<TYPES>& get_base_inter face();
virtual const tlm::tlm_bw_transport_i f<TYPES>& get_base_inter face() const;
virtual sc_core::sc_export<tl m::tlm_bw_transport_i f<TYPES> >& get_base_export();
virtual const sc_core::sc_export<tlm::tlm_bw_transport_if <TYPES> >& get_base_export() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


533
Copyright 2012 IEEE. All rights reserved.
virtual void bind(base_target_socket_type& s);
void oper ator () (base_target_socket_type& s);
// SystemC standard call back
// multi_passthrough_i ni ti ator_socket::bef ore_end_of_elaboration must be called from
// any derived cl ass
void before_end_of_elaboration();
// Bind multi i ni ti ator socket to mul ti i nitiator socket (hierarchical bind)
virtual void bind(base_type& s);
void oper ator () (base_type& s);
tl m::tlm_f w_transport_if <TYPES>* oper ator[ ](int i );
unsi gned int size();
} ;
templ ate <
typename MODULE,
unsi gned int BUSWIDTH = 32,
typename TYPES = tl m::tl m_base_protocol _types,
unsi gned int N=0,
sc_core::sc_port_poli cy POL = sc_core::SC_ONE_OR_MORE_BOUND
>
class multi_passthrough_target_socket : public mul ti _tar get_base< BUSWIDTH, TYPES, N, POL>
{
publ ic:
typedef typename TYPES::tlm_payload_type transaction_type;
typedef typename TYPES::tlm_phase_type phase_type;
typedef tl m::tl m_sync_enum sync_enum_type;
typedef sync_enum_type
(MODULE::* nb_cb)(int, transaction_type& , phase_type& , sc_core::sc_time&);
typedef voi d (MODULE::* b_cb)(i nt, transaction_type&, sc_core::sc_time& );
typedef unsigned i nt (MODULE::* dbg_cb)(i nt, transacti on_type& txn);
typedef bool (MODULE::* dmi _cb)(i nt, transaction_type& txn, tlm::tlm_dmi & dmi);
typedef multi_target_base<BUSWIDTH, TYPES, N, POL> base_type;
typedef typename base_type::base_i nitiator_socket_type base_i nitiator_socket_type;
typedef typename base_type::ini tiator_socket_type ini ti ator_socket_type;
multi_passthrough_target_socket();
multi_passthrough_target_socket(const char* name);
~multi_passthrough_target_socket();
void register _nb_transpor t_fw (MODULE* mod, nb_cb cb);
void register _b_tr anspor t (MODULE* mod, b_cb cb);
void register _tr anspor t_dbg (MODULE* mod, dbg_cb cb);
void register _get_direct_mem_ptr (MODULE* mod, dmi_cb cb);
// Overri de vi rtual f unctions of the tlm_target_socket:
virtual tlm::tlm_f w_transport_if <TYPES>& get_base_inter face();
virtual const tlm::tlm_f w_transport_i f<TYPES>& get_base_inter face() const;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


534
Copyright 2012 IEEE. All rights reserved.
virtual sc_core::sc_export<tl m::tlm_f w_transport_if <TYPES> >& get_base_export();
virtual const sc_core::sc_export<tl m::tlm_f w_transport_if <TYPES> >& get_base_export() const;
// SystemC standard call back
// multi_passthrough_target_socket::end_of_el aboration must be call ed from any deri ved class
void end_of_elabor ation();
virtual void bind(base_type& s);
void oper ator () (base_type& s);

tl m::tlm_bw_transport_i f<TYPES>* oper ator [] (i nt i );
unsi gned int size();
} ;
} // namespace tl m_uti ls
16.1.4.4 Rules
a) The base classes mul ti _i ni t_base and mul ti _tar get_base are impl ementation-defi ned, and shoul d not
be used directly by appli cations.
b) Each constructor shal l cal l the constructor of the correspondi ng base class passi ng through the char *
argument, i f there i s one. I n the case of the def ault constructors, the char * argument of the base class
constructor shal l be set to sc_gen_unique_name ("multi _passthrough_i ni ti ator_socket"), or
sc_gen_unique_name ("mul ti _passthrough_target_socket"), respectively.
c) Cl ass multi_passthrough_initiator _socket and cl ass multi_passthrough_target_socket each act
as multi-sockets; that i s, a si ngl e ini ti ator socket can be bound to multiple target sockets, and a si ngl e
target socket can be bound to multiple ini ti ator sockets. The two cl ass templates have template
parameters speci fying the number of bi ndings and the port bi ndi ng poli cy, which are used wi thi n the
class i mplementation to parameterize the associated sc_por t templ ate i nstanti ati on.
d) A single multi_passthrough_initiator _socket can be bound to many tlm_tar get_sockets and/or
many simple_target_sockets and/or many passthr ough_tar get_sockets and/or many
multi_passthrough_tar get_sockets. Many tlm_initiator _socketsand/or simple_initiator _sockets
and/or multi_passthrough_initiator s_sockets can be bound to a si ngl e
multi_passthrough_target_socket.
e) A multi_passthrough_initiator _socket can be bound hierarchi cally to exactly one other
multi_passthrough_initiator _socket. A multi_passthrough_target_socket can be bound
hierarchi cal ly to exactl y one other multi_passthrough_target_socket. Other than these two
specif ic cases, a mul ti -socket cannot be bound hierarchicall y to another socket. The mul ti ple bindi ng
capabil ities of mul ti -sockets do not appl y to hi erarchical bi ndi ng but onl y appl y when bi nding one or
more i ni ti ator sockets to one or more target sockets.
f ) The i mplementati on of each oper ator () shall achi eve its ef fect by cal li ng the correspondi ng virtual
method bind.
g) The bi ndi ng operators can only be used in the di rection i ni ti ator-socket-to-target-socket. I n other
words, unli ke cl asses tlm_tar get_socket and simple_tar get_socket, class
multi_passthrough_target_socket does not have operators to bi nd a target socket to an i ni ti ator
socket.
h) I n the case of hi erarchical binding (Fi gure 36), an i ni ti ator mul ti -socket of a chil d module shal l be
bound to an ini ti ator multi-socket of a parent module, and a target mul ti -socket of a parent modul e
bound to a target multi-socket of a chil d module. This i s consi stent wi th the initiator-to-target bi nd-
ing direction rule given above.
i) I f an object of cl ass multi_passthrough_initiator _socket or multi_passthrough_target_socket i s
bound multiple ti mes, then the method oper ator [] can be used to address the corresponding obj ect
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


535
Copyright 2012 IEEE. All rights reserved.
to which the socket i s bound. The index value i s determi ned by the order i n whi ch the methods bind
or oper ator () were call ed to bind the sockets. Thi s same i ndex val ue is used to determine the i d tag
passed to a cal lback.
j) For exampl e, consider a multi_passthrough_initiator _socket bound to two separate targets. The
cal ls socket[0]->nb_transpor t_fw(...) and socket[1]->nb_tr ansport_fw() would address the two
targets, and i ncomi ng nb_tr anspor t_bw() method cal ls from those two targets would carry the tags
0 and 1, respectively.
k) The method size shal l return the number of socket instances to whi ch the current multi-socket has
been bound. As f or SystemC multi-ports, if size i s call ed duri ng el aboration and before the call back
end_of_elabor ation, the val ue returned is i mplementati on-def ined because the time at whi ch port
binding is compl eted i s i mplementati on-def ined.
l ) I n the absence of hi erarchical binding to a multi-socket on a chi ld module, a target should regi st er
b_tr anspor t and nb_tr anspor t_fw call backs with a target multi-socket. Not doi ng so wil l resul t i n
a run-time error if and only if the corresponding method is call ed.
m) I n the absence of hi erarchi cal binding to a multi-socket on a chil d module, a target is not obli ged to
register a tr anspor t_dbg call back wi th a target mul ti-socket, i n which case an i ncomi ng
transpor t_dbg cal l shal l return with a value of 0.
n) I n the absence of hi erarchi cal binding to a multi-socket on a chil d module, a target is not obli ged to
register a get_dir ect_mem_ptr call back wi th a target mul ti -socket, in whi ch case an incoming
get_dir ect_mem_ptr cal l shal l return with a value of f alse.
o) I n the absence of hi erarchi cal bindi ng to a multi-socket on a chil d module, an i niti ator should
register an nb_tr anspor t_bw call back wi th an ini tiator mul ti -socket. Not doing so wil l result i n a
run-time error i f and only i f the nb_tr ansport_bw method is call ed.
p) I n the absence of hierarchi cal bi nding to a mul ti -socket on a chi ld module, an ini tiator is not obl iged
to register an invalidate_direct_mem_ptr call back wi th an i ni ti ator multi-socket, in whi ch case an
incoming invalidate_direct_mem_ptr cal l shal l be i gnored.
Exampl e:
// Initiator component with a multi-socket
struct I nitiator: sc_module
{
tl m_uti ls::multi_passthrough_i nitiator_socket<I nitiator> socket;
SC_CTOR(Initiator) : socket("socket") {
// Regi ster cal lback methods with socket
socket.register_nb_transport_bw(thi s, & Initiator::nb_transport_bw);
socket.register_i nval idate_di rect_mem_ptr(thi s, &I nitiator::i nval idate_di rect_mem_ptr);
...
} ;
struct I nitiator_parent: sc_modul e
{
tl m_uti ls::multi_passthrough_i nitiator_socket<I nitiator_parent> socket;
Ini ti ator * initiator;
SC_CTOR(Initiator_parent) : socket("socket") {
ini ti ator = new I nitiator("ini ti ator");
// Hierarchi cal bi ndi ng of i nitiator socket on child to i niti ator socket on parent
ini ti ator->socket.bi nd( socket );
}
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


536
Copyright 2012 IEEE. All rights reserved.
Figure 36Hierarchical binding of multi-sockets
struct Target: sc_module
{
tl m_uti ls::multi_passthrough_target_socket<Target> socket;
SC_CTOR(Target) : socket("socket") {
// Regi ster cal lback methods with socket
socket.register_nb_transport_f w( thi s, &Target::nb_transport_f w);
socket.register_b_transport( this, &Target::b_transport);
socket.register_get_direct_mem_ptr(thi s, &Target::get_direct_mem_ptr);
socket.register_transport_dbg( this, &Target::transport_dbg);
...
} ;
// Target component with a multi-socket
struct Target_parent: sc_modul e
{
tl m_uti ls::multi_passthrough_target_socket<Target_parent> socket;
Target * target;
SC_CTOR(Target_parent) : socket("socket") {
target = new Target("target");
// Hierarchi cal bi ndi ng of target socket on parent to target socket on chil d
socket.bind( target->socket );
}
} ;
Initiator
child module
Initiator_parent
Target
child module
Target_parent
Initiator
child module
Initiator_parent
Target
child module
Target_parent
multi_passthrough_initi ator_socket multi_passthrough_target_socket
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


537
Copyright 2012 IEEE. All rights reserved.
SC_MODULE(Top)
{
Ini ti ator_parent * i ni ti ator1;
Ini ti ator_parent * i ni ti ator2;
Target_parent * target1;
Target_parent * target2;
SC_CTOR(Top)
{
// Instanti ate two i nitiator and two target components
ini ti ator1 = new Ini ti ator_parent("i ni ti ator1");
ini ti ator2 = new Ini ti ator_parent("i ni ti ator2");
target1 = new Target_parent ("target1");
target2 = new Target_parent ("target2");
// Bind two i ni ti ator mul ti-sockets to two target mul ti -sockets
ini ti ator1->socket.bi nd( target1->socket );
ini ti ator1->socket.bi nd( target2->socket );
ini ti ator2->socket.bi nd( target1->socket );
ini ti ator2->socket.bi nd( target2->socket );
}
} ;
16.2 Quantum keeper
16.2.1 Introduction
Temporal decoupli ng permits SystemC processes to run ahead of si mulation ti me for an amount of ti me
known as the time quantum (see Cl ause 12 and Figure 37).
The util ity class tlm_quantumkeeper provides a set of methods f or managi ng and interacti ng wi th the ti me
quantum. When usi ng temporal decoupli ng, use of the quantum keeper i s recommended in order to maintain
a consi stent coding style. However, i t is strai ghtf orward in pri nci ple to implement temporal decoupl ing
directl y in SystemC. Whether or not the util ity cl ass tlm_quantumkeeper is used, al l temporal ly decoupl ed
models shoul d reference the global quantum mai ntained by the class tlm_global_quantum.
Cl ass tlm_quantumkeeper is in namespace tlm_utils.
For a general descripti on of temporal decoupli ng, see 10.3.2.
For a description of ti mi ng annotation, see 11.1.3.
16.2.2 Header file
The class defi ni ti ons for the quantum keeper shall be in the header fi le tlm_utils/tlm_quantumkeeper.h.
16.2.3 Class definition
namespace tl m_util s {
class tlm_quantumkeeper
{
publ ic:
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


538
Copyright 2012 IEEE. All rights reserved.
stati c void set_global_quantum( const sc_core::sc_ti me& );
stati c const sc_core::sc_time& get_global_quantum();

tlm_quantumkeeper ();
virtual ~tlm_quantumkeeper ();

virtual void inc( const sc_core::sc_ti me& );
virtual void set( const sc_core::sc_time& );
virtual sc_core::sc_ti me get_cur rent_time() const;
virtual sc_core::sc_ti me get_local_time();
virtual bool need_sync() const;
virtual void sync();
void set_and_sync(const sc_core::sc_ti me& t)
{
set(t);
if (need_sync())
sync();
}
virtual void reset();

protected:
virtual sc_core::sc_ti me compute_local_quantum();
} ;
} // namespace tl m_uti ls
16.2.4 General guidelines for processes using temporal decoupling
a) For maximum simul ation speed, all i ni ti ators shoul d use temporal decoupl ing, and the number of
other runnable SystemC processes should be zero or minimized.
b) I n an ideal scenario, the onl y runnabl e SystemC processes wi ll bel ong to temporall y decoupled
ini ti ators, and each process wil l run ahead to the end of i ts time quantum bef ore yi el ding to the
SystemC kernel .
c) A temporall y decoupled i ni ti ator is not obli ged to use a time quantum if communicati on with other
processes is expl icitly synchronized. Where a time quantum is used, it should be chosen to be l ess
than the typical communication interval between ini ti ators; otherwi se, important process
interactions may be l ost, and the model may be broken.
d) Yi el d means cal l wait i n the case of a thread process, or return f rom the f unction i n the case of a
method process.
e) Temporal decoupl ing runs i n the context of the standard SystemC si mulati on kernel, so events can
be scheduled, processes suspended and resumed, and l oosely-ti med models can be mi xed wi th other
codi ng styl es.
f ) There i s no obl igati on f or every i ni ti ator to use temporal decoupl ing. Processes with and without
temporal decoupl ing can be mixed. However, any process that i s not temporal ly decoupled is l ikely
to become a si mulati on speed bottl eneck.
g) Each temporall y decoupled initiator may accumulate any local processi ng del ays and
communication delays in a local vari abl e, referred to in this clause as the l ocal ti me offset. I t is
recommended that the quantum keeper should be used to maintai n the l ocal ti me off set.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


539
Copyright 2012 IEEE. All rights reserved.
h) Call sto the sc_time_stamp method wil l return the si mulati on timeasi t was at or near the start of
thecurrent ti mequantum.
Figure 37QuantumKeeper terminology
i) Thel ocal timeoffset i sunknown to theSystemC schedul er. Whenusing thetransport i nterfaces, the
local timeoffset shoul d bepassed asan argument to theb_transport or nb_transpor t methods.
j) Useof thenb_transpor t method wi th temporal decoupli ng and thequantumkeeper isnot ruled out,
but i t is not usuall y advantageous because the speed advantage to be gai ned from temporal
decoupli ng would be null ified by the high degree of i nter-process communi cation inherent in the
approxi mately-ti med coding style.
k) The order in whi ch processes resume wi thin the quantum i s under the control of the SystemC
schedul er and, by the rules of SystemC, i s indeterminate. In the absence of any expli ci t
synchronizati on mechanism, if a variable ismodi fi ed by onesuch processand read by another, the
val ueto beread wil l bei ndetermi nate. Thenew valuemay becomeavai labl ein thecurrent quantum
or the next quantum, assuming i t only changes rel ati vel y infrequentl y compared to the quantum
length, and the appl ication woul d need to be tolerant of preci sely when the new val ue becomes
avai lable. If thisis not thecase, theappl icati on shoul dguard thevariableaccesswith an appropriate
synchronizati onmechani sm.
l ) Any access to avariableor obj ect fromatemporall y decoupl ed processwi ll givethevalueit had at
thestart of thecurrent ti mequantumunlessit hasbeen modified by thecurrent processor by another
temporal ly decoupl ed process that has al ready run i n the current quantum. In parti cul ar, any
sc_signal accessed fromatemporally decoupl ed processwil l havethesamevalueit had at thestart
of thecurrent ti mequantum. Thi sisaconsequenceof thefact that conventional SystemCsimul ation
ti me(asreturned by sc_time_stamp) doesnot advancewi thin thequantum.
16.2.5 Class tlm_quantumkeeper
a) The constructor shal l set the l ocal ti me offset to SC_ZERO_TIME but shall not call the virtual
method compute_local_quantum. Becausetheconstructor doesnot cal cul atethelocal quantum, an
appl icati on shoul dcall themethod reset immedi ately after constructing aquantum keeper obj ect.
Gl obal quantum Gl obal quantum
Local timeoffset
Effective
Local timeoffset
sc_ti me_stamp()
Time
Initiator 1, fi rst torun in 2ndquantum
Initiator 2, currentl y runni ng
Initiator 3, not yet run in 2nd quantum
local time
Effective
local time
Integer mul tipl eof
global quantum
Local quantum
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


540
Copyright 2012 IEEE. All rights reserved.
b) The i mplementati on of cl ass tlm_quantumkeeper shall not create a stati c object of class sc_time,
but the constructor may create obj ects of cl ass sc_time. Thi s impl ies that an applicati on may call
f uncti on sc_cor e::sc_set_time_r esolution bef ore, and only before, constructing the f irst quantum
keeper object.
c) The method set_global_quantum shall set the value of the gl obal quantum to the value passed as an
argument, but it shall not modif y the l ocal quantum. The method get_global_quantum shall return
the current val ue of the global quantum. After cal li ng set_global_quantum, i t i s recommended to
cal l the method reset to recalculate the local quantum.
d) The method get_local_time shall return the value of the local ti me of fset.
e) The method get_cur rent_time shall return the val ue of the eff ective l ocal time, that is,
sc_time_stamp() + local_time_offset.
f ) The method inc shal l add the val ue passed as an argument to the local ti me of f set.
g) The method set shal l set the value of the local ti me of fset to the value passed as an argument.
h) The method need_sync shall return the value true if and onl y i f the local ti me off set i s greater than
the local quantum.
i) The method sync shal l call wait( local_time_offset ) to suspend the process unti l simul ati on time
equals the ef f ecti ve l ocal time, and shal l then call method reset.
j ) The method set_and_sync is a conveni ence method to call set, need_sync, and sync in sequence. It
should not be overridden.
k) The method reset shal l call the method compute_local_quantum and shall set the local ti me off set
back to SC_ZERO_TIME.
l ) The method compute_local_quantum of class tlm_quantumkeeper shall call the method
compute_local_quantum of class tlm_global_quantum, but it may be overridden i n order to
cal cul ate a small er val ue for the l ocal quantum.
m) The class tlm_quantumkeeper should be consi dered the default i mplementati on for the quantum
keeper. Appli cations may deri ve thei r own quantum keeper f rom cl ass tlm_quantumkeeper and
overri de the method compute_local_quantum, but this is unusual .
n) When the l ocal ti me off set i s greater than or equal to the l ocal quantum, the process shoul d yi eld to
the kernel . It i s strongl y recommended that the process does this by cal li ng the sync method.
o) There i s no mechani sm to enf orce synchroni zation at the end of the time quantum. It i s the
responsibi lity of the i nitiator to check need_sync and call sync as needed.
p) The b_tr anspor t method may i tself yi el d such that the val ue of sc_time_stamp can be di ff erent
bef ore and af ter the cal l. The value of the l ocal ti me off set and any ti ming annotati ons are always
expressed rel ative to the current value of sc_time_stamp. On return from b_tr anspor t or
nb_tr anspor t_fw, it is the responsibi li ty of the initiator to set the l ocal time off set of the quantum
keeper by call ing the set method, and then to check for synchronization by call ing the need_sync
method.
q) I f an i nitiator needs to synchroni ze bef ore the end of the ti me quantum; that i s, if an i ni ti ator needs to
suspend execution so that si mulati on ti me can catch up with the l ocal time, it may do so by call ing
the sync method or by expli ci tl y wai ti ng on an event. Thi s gives any other processes the chance to
execute, and it is known as synchronization-on-demand.
r) Making frequent calls to sync wil l reduce the eff ectiveness of temporal decoupl ing.
Exampl e:
struct I nitiator: sc_module // Loosely-timed ini tiator
{
tl m_uti ls::si mple_initiator_socket<Initiator> init_socket;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


541
Copyright 2012 IEEE. All rights reserved.
tlm_utils::tlm_quantumkeeper m_qk; // The quantum keeper
SC_CTOR(Initiator) : i nit_socket("ini t_socket") {
SC_THREAD(thread); // The initiator process
...
m_qk.set_global_quantum( sc_time(1, SC_US) ); // Repl ace the gl obal quantum
m_qk.reset(); // Re-cal cul ate the l ocal quantum
}
void thread() {
tl m::tlm_generic_payload trans;
sc_time del ay;
trans.set_command(tlm::TLM_WRITE_COMMAND);
trans.set_data_length(4);
f or (i nt i = 0; i < RUN_LENGTH; i += 4) {
int word = i;
trans.set_address(i);
trans.set_data_ptr( (unsigned char* )(&word) );
del ay = m_qk.get_l ocal _time(); // Annotate b_transport with l ocal time
ini t_socket->b_transport(trans, delay );
qk.set( delay ); // Update qk with ti me consumed by target
m_qk.inc( sc_time(100, SC_NS) ); // Further time consumed by initiator
if ( m_qk.need_sync() ) m_qk.sync(); // Check l ocal time agai nst quantum
}
}
...
} ;
16.3 Payload event queue
16.3.1 Introduction
A payload event queue (PEQ) i s a class that maintains a queue of SystemC event noti fi cati ons, where each
noti fi cati on carries an associated transaction obj ect. Each transacti on i s written into the PEQ annotated with
a del ay, and each transacti on emerges from the back of the PEQ at a ti me cal cul ated f rom the current
simul ation ti me pl us the annotated del ay.
Two payl oad event queues are provided as util ities. As well as bei ng usef ul in thei r own ri ght, the PEQ i s of
conceptual relevance in understanding the semantics of timing annotati on wi th the approximately-timed
codi ng styl e. However, i t i s possi bl e to implement approxi mately-ti med models wi thout using the specif ic
payl oad event queues given here. I n an approximatel y-ti med model , i t is of ten appropriate f or the reci pient
of a transaction passed using nb_transpor t to put the transaction into a PEQ wi th the annotated del ay. The
PEQ wil l schedul e the ti ming poi nt associ ated wi th the nb_transpor t cal l to occur at the correct si mulati on
ti me.
Transacti ons are inserted into a PEQ by cal ling the notify method of the PEQ, passi ng a delay as an
argument. There is also a notify method that schedules an immediate noti fi cation. The delay is added to the
current simul ation ti me (sc_time_stamp) to calculate the time at which the transaction wil l emerge f rom the
back end of the PEQ. The scheduli ng of the events is managed i nternally usi ng a SystemC ti med event
noti fi cati on, exploiting the property of cl ass sc_event that i f the notify method is cal led whil e there i s a
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


542
Copyright 2012 IEEE. All rights reserved.
notif i cati on pending, the noti fi cation wi th the earl iest simul ati on time wil l remai n whil e the other notif ication gets
cancelled.
Transacti ons emerge i n dif ferent ways f rom the two PEQ variants. I n the case of peq_with_get, the method
get_event returns an event that is noti fi ed whenever a transaction i s ready to be retrieved. The method
get_next_tr ansaction should be call ed repeatedl y to retrieve any avai lable transacti ons one at a ti me.
I n the case of peq_with_cb_and_phase, a call back method i s registered as a constructor argument, and that
method i s call ed as each transacti on emerges. This particular PEQ carries both a transaction obj ect and a phase
object with each noti fi cation, and both are passed as arguments to the cal lback method.
For an example, see 15.1.
16.3.2 Header file
The class defi nitions f or the two payload event queues shal l be i n the header f il es tlm_utils/peq_with_get.h and
tlm_utils/peq_with_cb_and_phase.h.
16.3.3 Class definition
namespace tl m_util s {
templ ate <class PAYLOAD>
class peq_with_get : publi c sc_core::sc_object
{
publ ic:
typedef PAYLOAD transaction_type;
peq_with_get(const char* name);
void notify( transacti on_type& trans, const sc_core::sc_ti me& t );
void notify( transacti on_type& trans );
transaction_type* get_next_transaction();
sc_core::sc_event& get_event();
void cancel_all();
} ;
templ ate<typename OWNER, typename TYPES=tlm::tlm_base_protocol_types>
class peq_with_cb_and_phase : publi c sc_core::sc_obj ect
{
publ ic:
typedef typename TYPES::tlm_payl oad_type tlm_payl oad_type;
typedef typename TYPES::tlm_phase_type tlm_phase_type;
typedef voi d (OWNER::* cb)(tl m_payl oad_type& , const tl m_phase_type&);

peq_with_cb_and_phase(OWNER* , cb );
peq_with_cb_and_phase(const char* , OWNER* , cb);
~peq_with_cb_and_phase();

void notify ( tlm_payload_type& , const tlm_phase_type& , const sc_core::sc_time& );
void notify ( tlm_payload_type& , const tl m_phase_type& );
void cancel_all();
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


543
Copyright 2012 IEEE. All rights reserved.
} // namespace tl m_uti ls
16.3.4 Rules
a) The notify method shal l i nsert a transaction into the PEQ. The transaction shall emerge f rom the
PEQ at ti me t1 + t2, where t1 is the value returned from sc_time_stamp() at the ti me notify i s
cal led, and t2 i s the value of the sc_time argument to notify. I n the case of immedi ate notif icati on,
the transaction shall emerge in the current eval uation phase of the SystemC scheduler.
b) Transacti ons may be queued i n any order and emerge i n the order gi ven by the previous rul e.
Transacti ons do not necessaril y emerge in the order in whi ch they were inserted.
c) There i s no li mi t to the number of transacti ons that may be in the PEQ at any given time.
d) If several transactions are queued to emerge at the same ti me, they shal l all emerge in the same
eval uation phase (that is, the same del ta cycle) i n the order in which they were i nserted.
e) The cancel_all method shall immedi ately remove al l queued transactions f rom the PEQ, eff ectivel y
restoring the PEQ to the state it had i mmediatel y af ter construction. This is the onl y way to remove
transactions from a PEQ.
f ) The PAYLOAD templ ate argument to class peq_with_get shal l be the name of the transaction type
used by the PEQ.
g) The get_event method shal l return a reference to an event that i s notif ied when the next transaction
is ready to emerge from the PEQ. I f more than one transacti on is ready to emerge in the same
eval uation phase (that is, in the same del ta cycl e), the event is notif ied once onl y.
h) The get_next_tr ansaction method shall return a poi nter to a transaction obj ect that i s ready to
emerge f rom the PEQ, and shall remove the transacti on obj ect from the PEQ. I f a transaction i s not
retri eved f rom the PEQ i n the evaluation phase i n whi ch the correspondi ng event noti fi cation occurs,
it wil l stil l be avail abl e f or retrieval on a subsequent call to get_next_tr ansaction at the current ti me
or at a later time.
i) If there are no more transactions to be retri eved in the current eval uati on phase,
get_next_tr ansaction shall return a null poi nter.
j) The TYPES template argument to class peq_with_cb_and_phase shall be the name of the protocol
traits class containing the transaction and phase types used by the PEQ.
k) The OW NER templ ate argument to cl ass peq_with_cb_and_phase shal l be the type of the class of
which the PEQ call back method is a member. This wi ll usuall y be the parent module of the PEQ
instance.
l) The OW NER* argument to the constructor peq_with_cb_and_phase shall be a pointer to the
object of whi ch the PEQ call back method is a member. Thi s wi ll usual ly be the parent modul e of the
PEQ instance.
m) The cb argument to the constructor peq_with_cb_and_phase shall be the name of the PEQ cal lback
method, which shall be a member f unction.
n) The i mplementation of class peq_with_cb_and_phase shal l cal l the PEQ cal lback method
whenever a transaction obj ect is ready to emerge f rom the PEQ. The f irst argument of the cal lback is
a ref erence to the transacti on obj ect and the second argument a reference to the phase object, as
passed to the correspondi ng notify method.
o) The i mplementation shall cal l the PEQ callback method f rom a SystemC method process, so the
cal lback method shall be non-blocki ng.
p) The implementati on shall only cal l the PEQ cal lback method once f or each transaction. After call ing
the PEQ call back method, the i mplementati on shal l remove the transacti on object from the PEQ.
The PEQ call back method may be cal led multipl e times i n the same evaluati on phase.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


544
Copyright 2012 IEEE. All rights reserved.
16.4 Instance-specific extensions
16.4.1 Introduction
The generi c payl oad contains an array of poi nters to extension objects such that each transacti on obj ect can
contai n at most one instance of each extensi on type. This mechani sm al one does not directl y permit mul ti pl e
instances of the same extension to be added to a gi ven transacti on obj ect. Thi s cl ause describes a set of
uti li ti es that provi de instance-speci fi c extensi ons, that is, mul ti pl e extensi ons of the same type added to a
single transacti on object.
An instance-speci fi c extensi on type is created using a class templ ate instance_specific_extension, used i n a
simi lar manner to class tlm_extension. Unl ike tlm_extension, applicati ons are not requi red or permitted to
impl ement vi rtual clone and copy_fr om methods. The access methods are restricted to set_extension,
get_extension, clear_extension, and resize_extensions. Automatic deleti on of instance-speci fi c extensions
is not supported, so a component cal ling set_extension should also call clear_extension. As for class
tlm_extension, method resize_extensions need onl y be cal led if a transaction obj ect is constructed during
stati c i niti alizati on.
An i nstance-specif ic extensi on is accessed usi ng an object of type instance_specific_extension_accessor.
This class provides a si ngl e method oper ator () that returns a proxy object through which the access methods
can be cal led. Each object of type instance_specific_extension_accessor gi ves access to a disti nct set of
extension objects, even when used wi th the same transaction obj ect.
I n the class def ini ti on i n 16.4.3, terms i n ital ics are impl ementation-defi ned names that should not be used
directly by an appli cation.
16.4.2 Header file
The cl ass defi ni ti ons f or the i nstance-specif ic extensi ons shal l be in the header f ile tlm_util s/
instance_specific_extensions.h
16.4.3 Class definition
namespace tl m_util s {
templ ate <typename T>
class instance_specific_extension : public i mpl ementati on-defi ned {
publ ic:
virtual ~instance_specific_extension();
} ;
templ ate<typename U>
class proxy {
publ ic:
templ ate <typename T> T* set_extension( T* );
templ ate <typename T> void get_extension( T* & ) const;
templ ate <typename T> void clear_extension( const T* );
void resize_extensions();
} ;
class instance_specific_extension_accessor {
publ ic:
instance_specific_extension_accessor ();

IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


545
Copyright 2012 IEEE. All rights reserved.
templ ate<typename T> proxy< i mpl ementati on-defi ned >& oper ator () ( T& );
} ;
} // namespace tl m_uti ls
Exampl e:
struct my_extn : tlm_utils::instance_specific_extension<my_extn> {
int num; // User-defi ned extension attribute
} ;
struct I nterconnect: sc_modul e
{
tl m_uti ls::si mple_target_socket<Interconnect> targ_socket;
tl m_uti ls::si mple_initiator_socket<Interconnect> i ni t_socket;
...
tlm_utils::instance_specific_extension_accessor accessor;
stati c i nt count;
virtual tl m::tlm_sync_enum nb_transport_fw(
tl m::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& del ay )
{
my_extn* extn;
accessor (trans).get_extension(extn); // Get existing extensi on
if (extn) {
accessor (trans).clear_extension(extn); // Delete exi sting extension
} else {
extn = new my_extn;
extn->num = count++;
accessor (trans).set_extension(extn); // Add new extensi on
}
return init_socket->nb_transport_fw( trans, phase, delay );
} ...
} ;
... SC_CTOR(Top) {
// Transaction obj ect passes thr ough two instancesof I nterconnect
interconnect1 = new Interconnect("i nterconnect1");
interconnect2 = new Interconnect("i nterconnect2");
interconnect1->i ni t_socket.bind( i nterconnect2->targ_socket );
...
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


546
Copyright 2012 IEEE. All rights reserved.
17. TLM-1 Message passing interface and analysis ports
The TLM-1 message passing i nterf ace compri ses the blocking and non-blocking put, get, peek, transport,
write, and analysi s interfaces, the tlm_fifo channel, the analysi s port, and the analysis f if o. The TLM-1
transport interf ace is disti nct from the TLM-2.0 transport i nterf ace.
17.1 Put, get, peek, and transport interfaces
17.1.1 Description
The TLM-1 message passi ng i nterf aces are f undamentall y dif ferent f rom the TLM-2 core interfaces in the
f ol lowi ng sense: Whereas the TLM-2 core interfaces pass a transacti on object by reference and the li fetime
of that transaction object may span mul ti ple i nterf ace method call s, the TLM-1 interfaces implement
message-passi ng semanti cs. With TLM-1 message passi ng semanti cs, the intent is that there shoul d be no
shared memory between call er and cal lee, and that the message-passing abstraction impl emented by TLM-1
interface method call s shoul d hide any internal state changes i n one SystemC modul e f rom any other
module. The TLM-1 bl ocki ng interfaces real ize synchronous message passi ng, and the TLM-1 non-blocking
interfaces reali ze asynchronous message passi ng.
TLM-1 message-passi ng, whi ch equates to transacti on-passi ng, i s unidi recti onal. The TLM-1 bi di recti onal
transport interface can be considered to be composed of two unidirecti onal message channels that pass
separate messages in opposing di recti ons. At an abstract l evel, the intent i s that the recipi ent of a transacti on
(whether that transacti on i s passed usi ng put or get) should receive the exact same value as was sent.
Message passing systems woul d typi cal ly i mplement this requi rement using stri ct pass-by-value semantics.
However, TLM-1 uses so-cal led ef fecti ve pass-by-val ue semantics, whereby although a transaction may i n
some cases be passed by reference, nei ther the cal ler nor the cal lee is permi tted to modi fy the transaction
object once it has been assi gned by the sender.
TLM-1 imposes a f urther constrai nt to ensure the integri ty of the message-passing semanti cs. The data type
of the transaction object should support deep copy semanti cs such that i f a copy is taken usi ng C++
ini ti al ization (copy constructor) or assignment, then a subsequent modif ication to the copy should not
modif y the ori gi nal transacti on object. I n other words, i f the transacti on obj ect contai ns any poi nters or
ref erences to shared memory outside of i tself , this standard does not specif y the ownership, li feti me, access,
or update rules f or such shared memory locations. Hence, the responsi bil ity f or the use of any such shared
memory l ies enti rely wi th the appli cation and should be careful ly documented.
In what fol lows, the term sender means the call er in the case of method put, or the cal lee i n the case of
methods get or peek, and the term r eci pi ent means the call ee in the case of put, or the cal ler in the case of
get of peek. I n the case of method transpor t, the cal ler is the sender of the request and the recipi ent of the
response, whereas the cal lee is the reci pient of the request and the sender of the response.
The transacti on obj ect is the object passed as an argument to the method put, nb_put, nb_get, nb_peek, or
transpor t, or as the return val ue f rom the method get, peek, or transpor t.
17.1.2 Class Definition
namespace tl m {
templ ate<cl ass T>
class tlm_tag { } ;
// Uni-directi onal bl ocking interfaces
template < typename T >
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


547
Copyright 2012 IEEE. All rights reserved.
class tlm_blocking_put_if : publi c vi rtual sc_core::sc_i nterf ace
{
publ ic:
virtual void put( const T &t ) = 0;
} ;
templ ate < typename T >
class tlm_blocking_get_if : publi c vi rtual sc_core::sc_i nterf ace
{
publ ic:
virtual T get( tlm_tag<T> * t = 0 ) = 0;
virtual void get( T & t ) { t = get(); }
} ;
templ ate < typename T >
class tlm_blocking_peek_if : publi c virtual sc_core::sc_interface
{
publ ic:
virtual T peek( tlm_tag<T> * t = 0 ) const = 0;
virtual void peek( T & t ) const { t = peek(); }
} ;
// Uni-directi onal non blocki ng i nterf aces
templ ate < typename T >
class tlm_nonblocking_put_if : publi c virtual sc_core::sc_interface
{
publ ic:
virtual bool nb_put( const T &t ) = 0;
virtual bool nb_can_put( tlm_tag<T> * t = 0 ) const = 0;
virtual const sc_core::sc_event &ok_to_put( tlm_tag<T> * t = 0 ) const = 0;
} ;
templ ate < typename T >
class tlm_nonblocking_get_if : publi c virtual sc_core::sc_interface
{
publ ic:
virtual bool nb_get( T & t ) = 0;
virtual bool nb_can_get( tlm_tag<T> * t = 0 ) const = 0;
virtual const sc_core::sc_event &ok_to_get( tlm_tag<T> * t = 0 ) const = 0;
} ;
templ ate < typename T >
class tlm_nonblocking_peek_if : publi c vi rtual sc_core::sc_i nterf ace
{
publ ic:
virtual bool nb_peek( T &t ) const = 0;
virtual bool nb_can_peek( tlm_tag<T> * t = 0 ) const = 0;
virtual const sc_core::sc_event &ok_to_peek( tlm_tag<T> * t = 0 ) const = 0;
} ;
// Uni-di recti onal combined bl ocking and non blocki ng i nterfaces
templ ate < typename T >
class tlm_put_if :
publ ic virtual tlm_blocking_put_i f< T > ,
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


548
Copyright 2012 IEEE. All rights reserved.
publ ic virtual tlm_nonbl ocking_put_if < T > { } ;
templ ate < typename T >
class tlm_get_if :
publ ic virtual tl m_blocki ng_get_i f< T > ,
publ ic virtual tlm_nonbl ocking_get_if < T > { } ;
templ ate < typename T >
class tlm_peek_if :
publ ic virtual tlm_blocking_peek_i f< T > ,
publ ic virtual tlm_nonbl ocking_peek_if < T > { } ;
// Uni-di recti onal combined get-peek interfaces
templ ate < typename T >
class tlm_blocking_get_peek_if :
publ ic virtual tl m_blocki ng_get_i f<T> ,
publ ic virtual tlm_blocking_peek_i f<T> { } ;
templ ate < typename T >
class tlm_nonblocking_get_peek_if :
publ ic virtual tl m_nonblocking_get_i f<T> ,
publ ic virtual tl m_nonbl ocking_peek_if<T> { } ;
templ ate < typename T >
class tlm_get_peek_if :
publ ic virtual tlm_get_if <T> ,
publ ic virtual tlm_peek_if <T> ,
publ ic virtual tlm_blocking_get_peek_if <T> ,
publ ic virtual tlm_nonbl ocking_get_peek_i f<T> { } ;
// Bidi rectional blocking transport interface
templ ate < typename REQ , typename RSP >
class tlm_transpor t_if : publi c virtual sc_core::sc_interface
{
publ ic:
virtual RSP transpor t( const REQ& ) = 0;
virtual void transpor t( const REQ& req , RSP& rsp ) { rsp = transport( req ); }
} ;
} // namespace tl m
17.1.3 Blocking versus non-blocking interfaces
a) The methods put, get, peek, and transpor t are blocki ng i nterf ace methods.
b) The methods nb_put, nb_can_put, ok_to_put, nb_get, nb_can_get, ok_to_get, nb_peek,
nb_can_peek, and ok_to_peek are non-bl ocki ng i nterf ace methods.
c) Bl ocking interface methods may cal l wait, directl y or indirectly.
d) Bl ocking interface methods shall not be cal led from a method process.
e) Non-bl ocking interface methods shall not call wait, directl y or indirectly.
f ) Non-bl ocking interface methods may be call ed f rom a thread process or f rom a method process.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


549
Copyright 2012 IEEE. All rights reserved.
17.1.4 Blocking put, get, peek, and transport
a) Consecutive cal ls to the put method and consecutive cal ls to the get method (through the same port
or export) shal l represent disti nct transacti on i nstances, regardless of whether or not the same
transacti on obj ect i s passed on each occasion. I n other words, on each cal l to put, the cal ler shall
pass the next transaction i n sequence, and on each return from get, the call ee shal l return the next
transaction in sequence.
b) The put method shall not return unti l the reci pi ent has accepted the transacti on object, that i s, unti l
the transaction object has been executed, copied, or passed downstream by the reci pi ent. I n other
words, on return f rom the put method, the cal ler can assume that the call ee has completed whatever
processing of the transaction obj ect was appropriate at that stage. The transaction may be executed
wi thin the body of the put method, or the put method may take a copy of the transaction obj ect f or
subsequent processing. I n ei ther case, the cal l er may attempt to send the next transaction
immedi ately.
c) The get method shall not return unti l the next transacti on object is ready to be returned. I n other
words, on return f rom the get method, the call er can assume that the call ee is returning a vali d
transaction object ready to be processed, and the call er may attempt to get the next transaction
immedi ately.
d) The peek method shal l not return unti l the next transacti on object i s ready to be returned. However,
unli ke the get method, the peek method shal l not remove the transacti on f rom the cal lee. In other
words, consecutive calls to peek (through the same port or export and with no intervening call to
get) shall return the same transaction object representing the same transaction instance. Si mil arl y, a
cal l to peek foll owed by a single cal l to get shall each return the same transaction object
representing the same transacti on i nstance.
e) The transpor t method shal l combi ne two uni di rectional transactions: a request object sent from
cal ler to cal lee and a response object sent from call ee to cal ler. The impl ementation of the transpor t
method shal l be semanti cal ly equi val ent to a cal l to put that passes the request obj ect foll owed by a
cal l to get that returns the correspondi ng response object. The response obj ect returned by the cal lee
shal l represent the response of the call ee to the given request obj ect. In other words, the entire
round-tri p transacti on shal l be executed in a single cal l to the transpor t method.
17.1.5 Non-blocking interface methods
a) The non-blocki ng interface methods each depend on being able to determine whether or not the
cal lee i s ready to accept (i n the case of nb_put) or to return (i n the case of nb_get and nb_peek) the
next transacti on immedi ately, that i s, as part of the executi on of the current non-bl ocking method
cal l. If the cal lee is abl e to respond i mmediately, then the non-bl ocking method (nb_put,
nb_can_put, nb_get, nb_can_get, nb_peek, or nb_can_peek) shall return the val ue true.
Otherwise, the non-bl ocking method shal l return the val ue false, and shal l not accept or return the
next transaction.
b) I f the i nterf ace methods nb_put, nb_get or nb_peek return the value true, they shall each behave as
would the correspondi ng blocki ng methods put, get or peek, respectively, except that they shal l
return immedi atel y without call ing wait.
c) I f the interface methods nb_put, nb_can_put, nb_get, nb_can_get, nb_peek, or nb_can_peek
return the val ue false, they shal l each return i mmedi ately wi thout accepting or returni ng a
transaction. In other words, they shal l not modi fy the state of the call ee wi th respect to sending or
receiving transactions using the parti cular port or export through which they are call ed.
d) The interface methods nb_put and nb_can_put shal l each return the same value (true or false) if
cal led i n place of one another at a given time through a given port or export. The return val ue shal l
not depend on the val ue of the transacti on object passed as an argument.
e) Simil arly, the i nterf ace methods nb_get, nb_can_get, nb_peek, and nb_can_peek shall each return
the same value (true or false) i f call ed in pl ace of one another at a given ti me through a given port or
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


550
Copyright 2012 IEEE. All rights reserved.
export. I n other words, i t i s not permitted that a cal lee would return true f or nb_get but false f or
nb_can_get, and vice versa, or true for nb_can_get but false for nb_can_peek, and vice versa.
f ) The interface methods ok_to_put, ok_to_get, and ok_to_peek shal l each return an sc_event that is
noti fi ed by the call ee whenever the cal lee becomes ready to accept or to return the next transaction.
The intent is that the notif icati on of thi s event can act as a cue to the cal ler to attempt to put, get, or
peek the next transacti on by calli ng one of the correspondi ng non-bl ocki ng i nterf ace methods
through the same port or export. However, the call er cannot assume that a non-bl ocking i nterf ace
method would necessari ly return the val ue true immedi ately f ol lowi ng the noti fi cation of one of
these events: The call er i s sti ll obli ged to check the val ue returned from the non-bl ocking interf ace
method.
g) There is no obli gation that the correspondi ng bl ocking and non-bl ocki ng i nterf ace methods have
consistent behavi or when call ed through the same port or export in pl ace of one another, although it
is recommended that they do. For exampl e, in ci rcumstances whereput woul d return immedi atel y, a
cal l to nb_put or nb_can_put should normall y return true, al though it i s not obl iged to do so.
Similarly, i n circumstances where put woul d call wait, a cal l to nb_put or nb_can_put should
normal ly return false, al though agai n it i s not obli ged to do so.
17.1.6 Argument passing and transaction lifetime
a) The argument of type tlm_tag<T>* may be used by the cal ler to di ff erentiate between template
instances i n the case where there exist multipl e instantiations of a TLM-1 interface that diff er onl y in
their transacti on type. The call er i s not obli ged to provi de a value f or this argument except as
required by the C++ l anguage rul es to disambi guate the method call . The body of the interf ace
method shall not use this argument.
b) I n the case of the i nterf ace methods put, nb_put, and transpor t, whi ch pass a transacti on obj ect as
a const reference argument (of type const T& , where T is a cl ass templ ate parameter), the cal ler
shal l ini ti al ize or assi gn the value of the transaction obj ect passed as the actual argument (the one-
and-onl y argument to put and nb_put and the fi rst argument to transport) wi th a val ue representing
the transaction instance bei ng sent bef ore executing the method call .
c) I n the case of the i nterf ace methods get, peek, nb_get, nb_peek, and transpor t, whi ch return a
transaction obj ect though a non-const reference argument (of type T& , where T is a class template
parameter), the call ee shal l (f or get, peek, transpor t) or may (f or nb_get, nb_peek) assign a value
to the f ormal argument representing the transacti on i nstance bei ng returned.
d) I n ei ther case, subsequent to initial izing or assigning a value to the actual or f ormal argument,
respecti vel y, neither call er nor call ee shal l modif y the val ue of thi s transaction object (di rectl y or
indirectly) until after the return from the i nterf ace method cal l, bearing in mind that i n some cases
the method cal l may bl ock and that there may exi st concurrent SystemC processes (withi n the call er
or the callee) wi th access to the actual or formal argument that may execute whil e the i nterf ace
method itsel f is suspended.
e) I n the case of the i nterf ace methods get, peek, and transpor t that have a non-void return type, the
transaction object i s returned by val ue, so the i ssue of modi fying the transacti on obj ect during the
method cal l does not arise.
f ) The li f etime of a transaction obj ect passed to a TLM-1 i nterf ace method is determined by the rul es
of the C++ l anguage, rememberi ng that a transaction obj ect is either passed as a reference argument
to an interf ace method call or is returned by value from an interface method call.
g) A transacti on obj ect passed as an argument to a TLM-1 interface method shall represent a val id
transaction i nstance f rom the poi nt when the correspondi ng actual or formal argument is initiali zed
or assi gned a value representing the transaction instance to the point f oll owing the return f rom the
interf ace method cal l. For exampl e, in the case of transpor t, the request obj ect i s vali d f rom the
point when it is i nitiali zed or assigned a val ue pri or to the call to transpor t to the poi nt f ollowi ng the
return f rom transpor t, and the response object i s val id f rom the poi nt when the f ormal argument is
assigned a val ue within the i mplementati on of transpor t to the point f oll owing the return f rom
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


551
Copyright 2012 IEEE. All rights reserved.
transpor t. (Thi s standard does not def ine any obl igations regarding the vali dity of the transacti on
object beyond this poi nt. I n other words, the transacti on object i s valid on return f rom the i nterf ace
method call, but i t i s up to each appl ication to determi ne the f ate of the transacti on obj ect from that
point on.)
h) The recipi ent of a transacti on may take a copy of the transaction object for subsequent processing, i n
which case the applicati on shall be responsible f or ensuring that the copy i s destroyed when it i s no
longer needed.
17.1.7 Constraints on the transaction data type
a) The intent of the recommendati on below i s to ensure the integri ty of the message-passing semanti cs
between sender and recipi ent, and to exclude the possibil ity of communi cation through shared
memory.
b) I f a transacti on obj ect contai ns poi nters or references, the reci pient of the transacti on should not
modif y the contents of the storage accessi ble through those poi nters or ref erences.
c) The data type of the transaction object shoul d have deep copy semanti cs such that i f the recipient
takes a copy of the actual or formal argument that represents the transacti on (usi ng C++
ini ti al izati on or assi gnment), any subsequent modifi cation to the copy should not modi f y the
ori ginal.
d) The above constraint coul d be met in various ways. For example, the transacti on object data type
coul d impl ement copy-on-write semanti cs such that the ori gi nal transaction and the copy both have
internal pointers to an area of shared memory, but any assignment to ei ther obj ect causes a separate
copy to be made.
e) The appl ication shal l provi de a destructor f or any transaction class that has non-trivial destruction
semanti cs (such as a transacti on with non-tri vi al deep copy semantics). The applicati on shal l be
responsibl e f or ensuri ng that each transaction obj ect is destroyed when i t i s no l onger requi red.
f ) If the transacti on object data type does not adhere to the above constraints, f or exampl e, i f i t creates
shal low copies of pointers, then i t is the responsibil ity of the appli cation to ensure that an
appropriate communication protocol i s f ol lowed to ensure message-passi ng semantics.
17.2 TLM-1 fifo interfaces
17.2.1 Description
Cl ass tlm_fifo_debug_if i s an i nterf ace proper that provi des debug access to a tlm_fifo. Cl ass
tlm_fifo_put_if and tlm_fifo_get_if are i nterf aces proper that combine the tlm_fifo_debug_if wi th the
tlm_put_if and the tlm_get_peek_if, respectively. Each of these three i nterf aces is impl emented by the
predef ined channel tlm_fifo.
17.2.2 Class Definition
namespace tl m {
// Fif o debug i nterface
templ ate< typename T >
class tlm_fifo_debug_if : publi c virtual sc_core::sc_i nterf ace
{
publ ic:
virtual int used() const = 0;
virtual int size() const = 0;
virtual void debug() const = 0;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


552
Copyright 2012 IEEE. All rights reserved.
virtual bool nb_peek( T & , i nt n ) const = 0;
virtual bool nb_poke( const T & , i nt n = 0 ) = 0;
} ;
// Fif o i nterf aces
templ ate < typename T >
class tlm_fifo_put_if :
publ ic virtual tlm_put_if <T> ,
publ ic virtual tlm_fi fo_debug_if <T> { } ;
templ ate < typename T >
class tlm_fifo_get_if :
publ ic virtual tlm_get_peek_if<T> ,
publ ic virtual tlm_fi fo_debug_if <T> { } ;
} // namespace tl m
17.2.3 Member functions
The f oll owing member functions are all pure vi rtual functi ons. The descriptions refer to the expected
def ini ti ons of the functions when overri dden i n a channel that impl ements this i nterf ace. The preci se
semanti cs wi ll be channel -speci fi c.
Member function used shal l return the number of i tems currentl y avai lable to be retri eved from the f if o
usi ng get or nb_get.
Member f unction size shal l return the current size of the fi fo, that i s, the maximum number of items that the
f if o can hold at any i nstant.
Member f unction debug shal l print di agnostic i nformation pertai ning to the current state of the f if o to
standard output.
Member f unction nb_peek shal l return a ref erence to the i tem at a gi ven posi ti on i n the fi fo, where posi tion
0 hol ds the i tem that wil l next be retrieved by get or nb_get, and posi ti on used()-1 hol ds the item most
recently inserted by put or nb_put. If there is no item at the gi ven position or the given posi ti on i s negative,
nb_peek shall return the value false, or otherwise true.
Member functi on nb_poke shall overwrite the i tem at a gi ven position i n the fi fo with another i tem passed
as an argument, where position 0 hol ds the item that wi ll next be retri eved by get or nb_get, and posi ti on
used()-1 hol ds the item most recentl y inserted by put or nb_put. I f there is no item at the given position or
the given posi ti on i s negative, nb_peek shal l return the value false, or otherwise true.
17.3 tlm_fifo
17.3.1 Description
Cl ass tlm_fifo is a predef ined pri mitive channel intended to model the behavior of a f i fo, that i s, a f irst-i n-
f irst-out buf fer. Each TLM f if o has a number of sl ots f or stori ng items. The number of slots i s set when the
object is constructed but a TLM fi fo may be resized after construction and may be unbounded. The primary
dif ferences between cl asses tlm_fifo and sc_fifo are that f irst, the tlm_fifo impl ements the TLM-1 message-
passing interf ace as opposed to the SystemC f if o i nterf ace, and second, a tlm_fifo may be resi zed or
unbounded rather than havi ng a fi xed size. I n the f ol lowi ng descripti on, the term fi fo ref ers to an object of
class tlm_fifo.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


553
Copyright 2012 IEEE. All rights reserved.
Each fi fo shal l impl ement the semantics of the tlm_put_if, tlm_get_if, tlm_peek_if, and tlm_fifo_debug_if
as described above by storing the sequence of transaction obj ects passed through those i nterf aces i n a single
f irst-i n-fi rst-out buff er. Cal ls to get or nb_get shal l retrieve transactions from the fi fo i n the same sequence
in whi ch transactions were previousl y inserted i nto the f if o usi ng call s to put or nb_put. Whenever a
transaction object i s retrieved f rom the f if o through a cal l to get or nb_get, the f if o shall not retai n any
internal copy of or ref erence to the retrieved transacti on object.
Cl ass tlm_fifo shall impl ement delta cycle semantics as described below.
17.3.2 Class Definition
namespace tl m {
templ ate <typename T>
class tlm_fifo :
publ ic virtual tlm_fi fo_get_if <T>,
publ ic virtual tlm_f if o_put_if <T>,
public sc_core::sc_pr im_channel
{
publ ic:
expl icit tlm_fifo( i nt size_ = 1 );
expl icit tlm_fifo( const char* name_, int si ze_ = 1 );
virtual ~tlm_fifo();
T get( tlm_tag<T> * t = 0 );
bool nb_get( T& );
bool nb_can_get( tlm_tag<T> * t = 0 ) const;
const sc_core::sc_event & ok_to_get( tlm_tag<T> * t = 0 ) const;
T peek( tlm_tag<T> * t = 0 ) const;
bool nb_peek( T& ) const;
bool nb_can_peek( tlm_tag<T> * t = 0 ) const;
const sc_core::sc_event & ok_to_peek( tlm_tag<T> * t = 0 ) const;
void put( const T& );
bool nb_put( const T& );
bool nb_can_put( tlm_tag<T> * t = 0 ) const;
const sc_core::sc_event& ok_to_put( tlm_tag<T> * t = 0 ) const;
void nb_expand( unsigned int n = 1 );
void nb_unbound( unsigned int n = 16 );
bool nb_reduce( unsigned int n = 1 );
bool nb_bound( unsigned i nt n );
bool nb_peek( T & , int n ) const;
bool nb_poke( const T & , i nt n = 0 );
int used() const;
int size() const;
void debug() const;
const char* kind() const;
} // namespace tl m
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


554
Copyright 2012 IEEE. All rights reserved.
17.3.3 Template parameter T
The typename argument passed to templ ate tlm_fifo shall be either a C++ type f or which the predefi ned
semanti cs f or assi gnment are adequate (for example, a fundamental type or a poi nter) or a type T that obeys
each of the fol lowing rul es:
a) I f the default assignment semantics are i nadequate to assign the state of the obj ect, the fol lowi ng
assignment operator should be defined for the type T. The implementation shal l use thi s operator to
copy the val ue being wri tten into a f if o slot or the value being read out of a f if o slot.
const T& operator= ( const T& );
b) I f any constructor f or type T exists, a default constructor for type T shal l be defi ned.
NOTE 1The assignment operator is not obli ged to assi gn the compl ete state of the obj ect, al though i t shoul d typi cal l y
do so. For exampl e, di agnosti c i nf ormati on may be associ ated wi th an obj ect that i s not to be propagated through the
f i f o.
NOTE 2The SystemC data types proper (sc_dt::sc_i nt, sc_dt::sc_l ogi c, and so forth) al l conf orm to the above rul e set.
NOTE 3It is legal to pass type sc_modul e* through a f i f o, al though thi s woul d be regarded as an abuse of the modul e
hi erarchy and thus bad practice.
17.3.4 Constructors and destructor
expl icit tlm_fifo( i nt size_ = 1 );
This constructor shall cal l the base class constructor f rom i ts ini tial izer li st as f ol lows:
sc_pri m_channel ( sc_gen_unique_name( "f if o" ) )
expl icit tlm_fifo( const char* name_, int si ze_ = 1 );
This constructor shall cal l the base cl ass constructor f rom its ini ti al izer li st as f ol lows:
sc_pri m_channel ( name_ )
Both constructors shal l ini ti al ize the number of sl ots i n the fi fo usi ng the value gi ven by the parameter si ze_.
This value may be positive, negative, or zero. A positive value shall indi cate a bounded fi fo of the given
size, and a negative val ue shal l i ndi cate an unbounded fi fo. A bounded fi fo may become ful l, an unbounded
f if o cannot become f ul l, and the behavior of a f if o with a size equal to 0 shal l be undefi ned.
virtual ~tlm_fifo();
The destructor shall del ete the f irst-i n-fi rst-out buf fer and shall del ete al l transaction objects.
17.3.5 Member functions
The member functions of the interf aces tlm_put_if, tlm_get_if, and tlm_peek_if shal l be i mplemented as
descri bed in 17.1 wi th the addi ti on of the del ta cycl e semantics descri bed i n 17.3.6.
void nb_expand( unsigned int n = 1 );
Member f unction nb_expand shall increase the si ze of a bounded f if o by the val ue passed as an
argument (new_si ze = previ ous_size + n), and shal l cause the event returned by ok_to_put to be
noti fied in the immediatel y f ollowi ng update phase of the f i fo. If the f if o i s unbounded, the behavior
of nb_expand shall be undef ined.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


555
Copyright 2012 IEEE. All rights reserved.
void nb_unbound( unsigned int n = 16 );
Member f unction nb_unbound shall cause the f if o to become unbounded, and shal l cause the event
returned by ok_to_put to be notif ied in the i mmediately f ol lowi ng update phase of the fi fo,
regardless of whether or not the f if o was previousl y unbounded. I f the val ue passed as an argument
is greater than the current si ze of the f if o, nb_unbound shal l resize the fi fo to that value; otherwise,
the si ze of the f if o shall remai n unaltered.
bool nb_reduce( unsigned int n = 1 );
Member f uncti on nb_reduce shall return true and shall reduce the si ze of a bounded fi f o by the
val ue passed as an argument provided that the new size is not less than the number of i tems currently
in the fi fo (new_size = max(previ ous_si ze - n, used)). If the proposed size i s l ess than the number of
items currentl y in the f if o nb_reduce shal l return false and shall reduce the si ze to the number of
items currentl y i n the fi fo. I f the f if o is unbounded, nb_reduce shal l return false wi thout modif ying
the si ze.
bool nb_bound( unsigned i nt n );
Member f uncti on nb_bound shall cause the f if o to become bounded regardl ess of whether or not the
f ifo was previousl y bounded. The si ze of the fi fo shal l be set to the value passed as an argument or to
the number of i tems currently in the fi fo, whi chever i s the greater (new_si ze = max(n, used)).
nb_bound shall return true i f and onl y if the new si ze of the fi fo i s equal to the val ue passed as an
argument.
bool nb_peek( T & , i nt n ) const;
Member function nb_peek shal l return the item at a gi ven posi ti on i n the f if o, where posi tion 0
holds the i tem that wil l next be retrieved by get or nb_get, and posi ti on used()-1 hol ds the i tem most
recently inserted by put or nb_put. I f there is no item at the given posi ti on or the gi ven positi on i s
negati ve, nb_peek shall return the value false, or otherwise true.
bool nb_poke( const T & , i nt n = 0 );
Member function nb_poke shal l overwrite the item at a gi ven posi ti on in the f if o with another item
passed as an argument, where posi ti on 0 holds the i tem that wil l next be retrieved by get or nb_get,
and position used()-1 hol ds the i tem most recentl y i nserted by put or nb_put. I f there i s no item at
the gi ven position or the given posi ti on is negative, nb_peek shal l return the value false, or
otherwi se true.
int used() const;
Member functi on used shall return the number of i tems currently avai lable to be retri eved f rom the
f ifo using get , nb_get, or nb_peek or modif ied usi ng nb_poke. Member functions put and nb_put
may cause the value of used to be increased i n the next update phase, member f unctions get and
nb_get may cause the val ue of used to be decreased i mmediately, and member f uncti ons peek,
nb_peek, and nb_poke shal l not change the val ue of used.
int size() const;
Member f unction size shal l return the current size of the f ifo, that is, the maxi mum number of i tems
that the f if o can hold at any instant. The f if o may be re-sized. A non-negative size shall indicate that
the f if o is bounded, that i s, can become f ul l. For non-negati ve si ze, member f unctions put, nb_put,
get, and nb_get shall not change the value of size. A negative size shall i ndi cated that the f if o i s
unbounded, in which case the actual val ue of size is undefi ned.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


556
Copyright 2012 IEEE. All rights reserved.
void debug() const;
Member functi on debug shall pri nt di agnostic i nf ormation pertai ning to the current state of the f if o
to standard output. The detai l of the diagnosti c information is undef ined.
const char* kind() const;
Member f uncti on kind shal l return the string "tlm_fifo".
17.3.6 Delta cycle semantics
Any transactions i nserted i nto the fi fo by call s to put or nb_put shall onl y become avail abl e to get, nb_get,
peek, or nb_peek in the next del ta cycl e, although they shal l have an immedi ate ef fect on any subsequent
cal ls to put or nb_put in the current evaluation phase with respect to the fi fo becomi ng f ul l.
Any vacated slots created in the fi fo by a call s to get or nb_get shall onl y become avail abl e to put or nb_put
in the next delta cycl e, although they shal l have an i mmediate ef fect on any subsequent cal ls to get or
nb_get in the current eval uation phase.
I n other words, cal ls to put, nb_put, get, or nb_get i n a gi ven evaluati on phase shal l cause rel evant state
variables to be modi fi ed in the update phase of the pri mitive channel such that the ef fect onl y becomes
visibl e in the i mmediatel y foll owing eval uation phase. Thi s shall i ncl ude the noti fi cation of the events
returned by the member functions ok_to_put, ok_to_get, and ok_to_peek.
For exampl e, a sequence of cal ls to put on an empty fi fo wi thin a given eval uation phase may cause the f if o
to become ful l and put to block, even though nb_get woul d stil l return false. Si mil arly, a sequence of call s
to get on a full fi fo within a gi ven evaluati on phase may cause the f if o to become empty and get to block,
even though nb_put would stil l return false.
The member f uncti ons nb_peek and nb_poke of cl ass tlm_fifo_debug_if do not have access to any
transactions i nserted i nto the f if o by call s to put or nb_put in the current evaluati on phase, nor do they have
access to any transctions already removed f rom the f if o by cal ls to get or nb_get in the current evaluati on
phase.
Exampl e:
struct Top: sc_modul e
{
typedef tl m_fi fo<int> fi fo_t;
fi f o_t * f if o;

Top(sc_module_name _name)
{
f if o = new fi fo_t(2); // Construct bounded f if o with size of 2
SC_THREAD(T1);
SC_THREAD(T2);
}
sc_dt::ui nt64 delta;
voi d T1()
{
sc_assert( f if o->size() == 2 );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


557
Copyright 2012 IEEE. All rights reserved.
f or (i nt i = 0; i < 4; i++)
f if o->put(i ); // The thi rd cal l wi ll bl ock

f if o->nb_expand(2); // Increase fi fo size
sc_assert( f if o->size() == 4 );

f or (i nt i = 4; i < 8; i++)
fi fo->put(i );
sc_assert( f if o->nb_reduce( 3) ); // Decrease f if o size
sc_assert( f if o->size() == 1 );

f or (i nt i = 8; i < 12; i++)
f if o->put(i ); // The second call will block
f if o->nb_unbound(); // Make f if o unbounded
sc_assert( f if o->size() < 0 );
del ta = sc_del ta_count();
f or (i nt i = 101; i <= 104; i ++)
fi fo->put(i );
sc_assert( sc_delta_count() == delta );
sc_assert( f if o->used() == 0 );
}

voi d T2()
{
f or (i nt i = 0; i < 12; i++)
sc_assert( f if o->get() == i );

sc_assert( f if o->get() == 101 );
sc_assert( f if o->used() == 3 );
sc_assert( sc_delta_count() == delta + 1 );

sc_assert( f if o->get() == 102 );
sc_assert( f if o->used() == 2 );
sc_assert( sc_delta_count() == delta + 1 );
sc_assert( f if o->get() == 103 );
sc_assert( f if o->used() == 1 );
sc_assert( sc_delta_count() == delta + 1 );

sc_assert( f if o->get() == 104 );
sc_assert( f if o->used() == 0 );
sc_assert( sc_delta_count() == delta + 1 );
}

SC_HAS_PROCESS(Top);
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


558
Copyright 2012 IEEE. All rights reserved.
17.4 Analysis interface and analysis ports
Analysi s ports are i ntended to support the di stri bution of transactions to multipl e components for analysis,
meani ng tasks such as checki ng for functional correctness or col lecti ng f unctional coverage stati stics. The
key feature of analysis ports i s that a si ngl e port can be bound to mul ti pl e channel s or subscri ber s such that
the port itself replicates each call to the interface method wr ite with each subscriber. An anal ysi s port can be
bound to zero or more subscribers or other anal ysis ports, and can be unbound.
Cl ass tlm_analysis_por t is derived f rom cl ass sc_object, not from class sc_por t, so an anal ysi s port is not
techni cal ly a port. Anal ysi s ports can be i nstanti ated, deleted, bound, and unbound dynamicall y duri ng
simul ation.
Each subscriber impl ements the wr ite method of the tlm_analysis_if. The method i s passed a const
ref erence to a transacti on, whi ch a subscriber may process immedi atel y. Otherwise, i f the subscri ber wishes
to extend the li feti me of the transaction, i t is obliged to take a deep copy of the transaction object, at which
point the subscri ber ef fecti vel y becomes the initiator of a new transaction and is thus responsi bl e f or the
memory management of the copy.
Analysi s ports should not be used i n the mai n operati onal pathways of a model, but only where data is
tapped off and passed to the side for anal ysi s. Interface tlm_analysis_if is deri ved from tlm_wr ite_if. The
latter i nterf ace is not speci fi c to analysis, and may be used for other purposes. For example, see 16.3.
The tlm_analysis_fifo is simpl y an i nf inite tlm_fifo that i mplements the tlm_analysis_if to write a
transaction to the fi fo.
17.4.1 Class definition
namespace tl m {
// Write i nterf ace
templ ate <typename T>
class tlm_wr ite_if : publi c vi rtual sc_core::sc_i nterf ace {
publ ic:
virtual void wr ite( const T& ) = 0;
} ;
// Anal ysi s i nterf ace
templ ate < typename T >
class tlm_analysis_if : publi c virtual tlm_write_i f<T>
{
} ;
// Anal ysi s port
templ ate < typename T>
class tlm_analysis_por t : publi c sc_core::sc_object , publi c vi rtual tlm_analysi s_i f< T >
{
publ ic:
tlm_analysis_por t();
tlm_analysis_por t( const char * );
// bind and () work f or both i nterfaces and anal ysi s ports,
// si nce anal ysis ports impl ement the analysis interface
virtual void bind( tlm_analysis_i f<T> & );
void oper ator () ( tlm_analysi s_i f<T> & );
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


559
Copyright 2012 IEEE. All rights reserved.
virtual bool unbind( tlm_anal ysi s_i f<T> & );
void wr ite( const T & );
} ;
// Anal ysi s f if o - an unbounded tlm_f if o
templ ate< typename T >
class tlm_analysis_fifo :
publ ic tl m_fi fo< T > ,
publ ic virtual tlm_anal ysi s_if < T > ,
publ ic:
tlm_analysis_fifo( const char *nm ) : tlm_fifo<T>( nm, 16 ) {}
tlm_analysis_fifo() : tlm_fifo<T>( 16 ) {}
void wr ite( const T & t ) { nb_put( t ); }
} ;
} // namespace tl m
17.4.2 Rules
a) tlm_wr ite_if and tlm_analysis_if (and thei r del ayed variants) are uni directi onal , non-negoti ated,
non-blocking transacti on-level interfaces, meaning that the cal lee has no choice but to accept
immedi ately the transaction passed as an argument.
b) The constructor shall pass any character string argument to the constructor bel onging to the base
class sc_object to set the stri ng name of the instance i n the module hierarchy.
c) The bind method shal l register the subscriber passed as an argument with the anal ysis port instance
so that any cal l to the wr ite method shall be passed on to the regi stered subscri ber. Multipl e
subscribers may be regi stered wi th a si ngl e anal ysi s port instance.
d) The i mplementati on of oper ator () shall achi eve its effect by call ing the vi rtual method bind.
e) There may be zero subscri bers registered with any given anal ysis port instance, i n whi ch case cal ls
to the wr ite method shall not be propagated.
f) The unbind method shall reverse the eff ect of the bind method; that is, the subscriber passed as an
argument shall be removed f rom the l ist of subscribers to that analysis port instance.
g) The bind and unbind methods can be call ed during elaboration or can be cal led dynamicall y duri ng
simul ation.
h) The wr ite method of cl ass tlm_analysis_port shall call the wr ite method of every subscriber
registered wi th that anal ysi s port instance, passing on the argument as a const ref erence.
i) The wr ite method is non-bl ocki ng. It shall not call wait.
j) The wr ite method shal l not modi fy the transaction object passed as a const ref erence argument, nor
shal l i t modi fy any data associ ated with the transaction object (such as the data and byte enable
arrays of the generi c payload).
k) I f the impl ementation of the wr ite method in a subscri ber is unable to process the transaction bef ore
returning control to the call er, the subscriber shall be responsibl e f or taking a deep copy of the
transaction obj ect and for managing any memory associated with that copy thereaf ter.
l) The constructors of class tlm_analysis_fifo shall each construct an unbounded tlm_fifo.
m) The wri te methods of class tlm_analysis_fifo shal l call the nb_put method of the base cl ass
tlm_fifo, passi ng on their argument to nb_put.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


560
Copyright 2012 IEEE. All rights reserved.
Exampl e:
struct Trans // Analysi s transacti on cl ass
{
int i ;
} ;
struct Subscriber: sc_obj ect, tlm::tlm_anal ysi s_i f<Trans>
{
Subscri ber(const char* n) : sc_obj ect(n) { }
virtual void wri te(const Trans& t)
{
cout << "Hel lo, got " << t.i << "\n"; // Impl ementation of the wri te method
}
} ;
SC_MODULE(Chil d)
{
tl m::tlm_anal ysi s_port<Trans> ap;
SC_CTOR(Chi ld) : ap("ap")
{
SC_THREAD(thread);
}
void thread()
{
Trans t = { 999} ;
ap.write(t); // Interface method cal l to the wri te method of the anal ysi s port
}
} ;
SC_MODULE(Parent)
{
tl m::tlm_anal ysi s_port<Trans> ap;
Chil d* chil d;
SC_CTOR(Parent) : ap("ap")
{
chi ld = new Chi ld("chi ld");
chi ld->ap.bind(ap); // Bind analysis port of chil d to analysis port of parent
}
} ;
SC_MODULE(Top)
{
Parent* parent;
Subscri ber* subscriber1;
Subscri ber* subscriber2;
SC_CTOR(Top)
{
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


561
Copyright 2012 IEEE. All rights reserved.
parent = new Parent("parent");
subscri ber1 = new Subscri ber("subscri ber1");
subscri ber2 = new Subscri ber("subscri ber2");
parent->ap.bind( * subscriber1 ); // Bind anal ysis port to two separate subscribers
parent->ap.bind( * subscriber2 ); // Thi s is the key f eature of analysis ports
}
} ;
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


562
Copyright 2012 IEEE. All rights reserved.
Annex A
(informative)
Introduction to SystemC
This annex i si nformativeand i si ntended to ai d thereader i ntheunderstanding of thestructureandi ntent of
theSystemCcl assl ibrary.
TheSystemCcl assl ibrary supportsthefunctional model ing of systems by providing cl assesto represent the
fol lowi ng:
The hierarchical decomposition of asystem i nto modules
The structural connectivity between thosemodulesusing ports and exports
The scheduling and synchronization of concurrent processes using events and sensitivity
The passing of simulated time
The separation of computation (processes) from communication (channels)
The independent refinement of computati on andcommunication usi ngi nterfaces
Hardware-oriented data typesfor model ing digital logic and fi xed-poi nt arithmeti c
Loosely speaki ng, SystemCal lowsauser to writeaset of C++ functions(processes) that areexecuted under
control of a schedul er i n an order that mi mics the passageof simulated ti me and that aresynchroni zed and
communi cate i n a way that is useful for model ing el ectronic systems containing hardware and embedded
software. Theprocessesareencapsulated in amodulehi erarchy that capturesthestructural rel ationshi psand
connectivi ty of the system. Inter-processcommunicati on uses amechani sm, the interfacemethod cal l, that
facil itiestheabstraction andi ndependent refinement of system-level interfaces.
Figure A-1SystemC language architecture
Application
Written by the end user
Methodology- and technology-specific libraries
SystemC verification library, bus models, TLMinterfaces
Core language Predefined channels Utilities Data types
Modules
Ports
Processes
Interfaces
Channels
Events
Signal, clock, FIFO,
mutex, semaphore
Report handling,
tracing
4-valued logic type
4-valued logic vectors
Bit vectors
Finite-precision integers
Fixed-point types
Programming language C++
Exports
Limited-precision integers
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


563
Copyright 2012 IEEE. All rights reserved.
Thearchitectureof aSystemCapplication i sshown in Fi gureA-1. Theshaded bl ocksrepresent theSystemC
class l ibrary i tself. The l ayer shown immedi ately above the SystemC class l ibrary represents standard or
propri etary C++ libraries associ ated wi th specific desi gn or verificati on methodol ogi es or speci fi c
communi cation channel sand i soutsidethescopeof thisstandard.
Theclasses of theSystemCl ibrary fal l into four categori es: the corelanguage, theSystemC datatypes, the
predefined channel s, and the uti li ties. The core language and the data types may beused i ndependently of
oneanother, al thoughthey aremoretypi cal ly used together.
At the core of SystemC is a si mulati on engine containing a process scheduler. Processes are executed in
responseto thenotification of events. Eventsarenoti fi ed at specific pointsin simul ated ti me. In thecaseof
ti me-ordered events, the schedul er is determi nisti c. In the case of events occurring at the same poi nt in
simul ation ti me, thescheduler i snon-determi nistic. Theschedul er isnon-preemptive(see4.2.1).
Themodul e is thebasic structural bui ldi ng bl ock. Systemsarerepresented by amodulehierarchy consisti ng
of aset of modul es rel ated by instantiati on. A modulecan contai n thefoll owing:
Ports (see 5.12)
Exports (see 5.13)
Channels (see 5.2 and 5.15)
Processes (see 5.2.10 and 5.2.11)
Events (see 5.10)
Instances of other modules (see 4.1.1)
Other data members
Other member functions
Modules, ports, exports, channels, i nterfaces, events, and ti mesarei mplementedasC++ cl asses.
The execution of a SystemC appl ication consi sts of el aborati on, duri ng whi ch the modul e hi erarchy i s
created, followed by si mul ati on, during which theschedul er runs. Both elaboration and simulati on i nvolve
the execution of code both from the appli cati on and fromtheker nel . The kernel is the part of a SystemC
class li brary impl ementation that provi desthecorefuncti onali ty for elaborati on and theschedul er.
Instances of ports, exports, channels, and modul es can only be created duri ng el aboration. Once created
during el aboration, thi shierarchical structureremainsfi xed for theremai nder of elaborati on and simulati on
(see Cl ause 4). Process i nstances can be created stati call y duri ng elaborati on (see 5.2.9) or dynami cal ly
duri ng si mulati on (see 5.5). Modules, channels, ports, exports, and processes are derived from a common
base class sc_object, whi ch provides methods for traversi ng the module hi erarchy. Arbi trary attri butes
(name-valuepai rs) can beattachedtoi nstancesof sc_object (see5.16).
Instances of ports, exports, channels, and modulescan only becreated wi thin modul es. Theonl y exception
to thi sruleis top-l evel modules.
Processes are used to perform computati ons and hence to model the functionali ty of a system. Although
noti onall y concurrent, processesareactual ly schedul ed to executein sequence. ProcessesareC++ functi ons
registered wi th the kernel during el aboration (stati c processes) or during si mulati on (dynamic processes),
and cal led fromthekernel during si mulati on.
Thesensi ti vi ty of aprocess identifiestheset of eventsthat would causethescheduler toexecutethat process
should thoseeventsbenotified. Bothstati c and dynami c sensi ti vi ty areprovi ded. Stati c sensitivity i screated
at thetimetheprocessi nstanceis created, whereasdynami c sensi tivi ty iscreated duri ng theexecution of the
functi on associ ated with the process duri ng si mulati on. A process may be sensi tive to named events or to
events buried within channel s or behi nd ports and l ocated usi ng an event fi nder . Furthermore, dynamic
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


564
Copyright 2012 IEEE. All rights reserved.
sensitivity may be created with a ti me-out, meani ng that the scheduler executes the process after a given
ti meinterval has el apsed(see4.2.1 and5.2.14 through 5.2.18).
Channels serve to encapsul ate the mechani smsthrough whi ch processes communicate and hence to model
thecommunication aspects or protocols of asystem. Channel scanbeused for i nter-modul ecommuni cation
or for inter-process communi cation within amodule.
Interfacesprovi deameansof accessing channels. An interfaceproper is an abstract class that declaresaset
of purevirtual functi ons (interfacemethods). A channel is said to i mpl ement an interface if i t definesall of
themethods (that is, member functi ons) declared in that interface. Thepurposeof i nterfacesi sto exploit the
object-oriented type system of C++ in order that channel s can be refi ned i ndependentl y from the modules
that usethem. Specificall y, any channel that i mplements aparticular interfacecan bei nterchanged with any
other such channel in acontext that namesthat interfacetype.
Themethodsdefi ned wi thin achannel are typically call ed through an i nterface. A channel may impl ement
morethan oneinterface, andasingleinterfacemay bei mplementedby morethanonechannel .
Interfacemethods impl emented in channel smay createdynami c sensitivity to events contai ned within those
same channels. Thi s i s a typical coding idiom and resul ts in a so-call ed bl ocking method in which the
processcall ing themethod i ssuspended unti l thegiven event occurs. Such methods can only becall ed from
certai nkinds of processesknown asthread processes(see5.2.10 and5.2.11).
Because processes and channels may be encapsulated withi n modules, communication between processes
(through channel s) may crossboundari es wi thi n themodulehierarchy. Such boundary crossi ng ismediated
by portsandexports, which serveto forward methodcal lsfrom theprocesseswi thi namoduleto channelsto
which thoseportsor exports are bound. A port speci fi es that a parti cul ar interface is requi red by a modul e,
whereasanexport speci fi es that aparti cul ar i nterfacei s provi ded by amodul e. Portsall ow interfacemethod
cal ls withi n amodul eto be independent of thecontext i n which themodul ei s instanti ated in thesensethat
the modul e need have no expl icit knowledge of the i dentity of the channels to whi ch its ports are bound.
Exports al low asi ngl emodul etoprovi demul tipl ei nstancesof thesamei nterface.
Ports belongi ng to specific modul e i nstances are bound to channel instances duri ng elaborati on. The port
binding pol icy can be set to control whether a port need be bound, but the bi ndi ng cannot be changed
subsequently. Exports are bound to channel i nstances that l ie wi thin or below the module contai ning the
export. Hence, each interface method call made through a port or export i s directed to a specific channel
instance in the elaborated module hierarchythe channel instance to which that port is bound.
Ports can only forward method cal ls up or out of amodule, whereas exports can onl y forward method call s
down or i nto amodule. Such methodcal lsal waysori ginatefromprocesseswi thin amodul eandaredirected
to channels instantiated elsewherein themodul ehi erarchy.
Portsand exportsareinstances of atempl atedcl assthat i sparameterizedwithan i nterfacetype. Theport or
export can only be bound to achannel that implements that parti cul ar interfaceor one derived from i t (see
5.12 through 5.14).
Therearetwo categories of channel : hierarchi cal channels and primiti vechannels. A hierarchi cal channel i s
amodul e. A pri mitivechannel is derived fromaspeci fi c basecl ass(sc_prim_channel) and i snot amodule.
Hence, a hi erarchical channel can contain processes and instances of modules, ports, and other channel s,
whereas a primi ti ve channel can contai n none of these. It i s al so possi ble to defi nechannels deri ved from
nei ther of thesebaseclasses, but every channel impl ementsoneor moreinterfaces.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


565
Copyright 2012 IEEE. All rights reserved.
A pri mi ti vechannel provi des uni queaccessto theupdatephaseof thescheduler, enabl ing thevery effi cient
implementation of certai n communicati on schemes. Thi s standard incl udes a set of predefined channels,
together wi th associ ated interfaces and ports, asfollows:
sc_signal (see6.4)
sc_buffer (see6.6)
sc_clock (see6.7)
sc_signal _resol ved (see6.13)
sc_signal _rv (see6.17)
sc_fifo(see6.23)
sc_mutex (see6.27)
sc_semaphore(see6.29)
sc_event_queue(see6.29)
Cl asssc_signal provides the semanti csfor creating register transfer level or pin-accurate models of di gital
hardware. Class sc_fifo provides the semanti cs for point-to-poi nt FIFO-based communi cation appropri ate
for model s based on networksof communicati ng processes. Classes sc_mutex and sc_semaphore provide
communication pri mitivesappropri atefor softwaremodel ing.
This standard includesaset of datatypesfor modeli ng di gital logic and fixed-poi nt ari thmeti c, asfoll ows:
sc_i nt<> (see7.5.4)
sc_uint<> (see7.5.5)
sc_bigi nt<> (see7.6.5)
sc_biguint<> (see7.6.6)
sc_l ogi c (see7.9.2)
sc_l v<> (see7.9.6)
sc_bv<> (see7.9.6)
sc_fixed<> (see7.10.18)
sc_ufi xed<> (see7.10.19)
Cl asses sc_int and sc_uint provide signed and unsigned l imi ted-precision integers wi th a word length
li mi ted by the C++ impl ementation. Cl asses sc_bigint and sc_biguint provide finite-precision integers.
Cl ass sc_logic provides four-val ued l ogi c. Classes sc_bv and sc_lv provide two- and four-val ued l ogi c
vectors. Cl assessc_fixedand sc_ufixed providesi gned and unsi gned fixed-point arithmetic.
Theclassessc_report and sc_report_handler provi deageneral mechani smfor error handli ng that isused
by theSystemC cl ass library itself and i salso avail abl eto theuser. Reportscan becategori zed by severi ty
and by message type, and customi zed acti ons can be set for each category of report, such as wri ti ng a
message, throwing an excepti on, or aborting theprogram (see8.2 and 8.3).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


566
Copyright 2012 IEEE. All rights reserved.
Annex B
(informative)
Glossary
This gl ossary contai ns bri ef, i nformal descri pti onsfor anumber of terms and phrases used in thisstandard.
Where appropriate, thecomplete, formal definition of each termor phrasei s given i n the mai n body of the
standard. Each glossary entry contains either the clause number of the defini ti on in the mai n body of the
standard or an indicati on that thetermis defi ned in ISO/IEC14882:2003.
B.1 abstract class: A cl ass that has or inheri ts at least onepurevirtual functi on that isnot overri dden by a
non-purevi rtual function. (C++ term)
B.2 adapter: A modul e that connects a transacti on l evel i nterface to a pi n l evel interface (in the general
sense of the word i nter face) or that connects together two transacti on level interfaces, often at di fferent
abstraction level s. An adapter may be used to convert between two sockets speci al ized wi th different
protocol types. See al so: bridge; transactor. (See14.2.2.)
B.3 application: A C++ program, wri tten by an end user, that usestheSystemCor TLM-2.0 cl assli brari es,
that is, uses cl asses, cal ls functi ons, uses macros, and so forth. An appli cati on may use as few or as many
features of C++ as is seenfit and asfew or as many featuresof SystemCasis seen fi t. (See3.1.2.)
B.4 approximately-timed: A modeli ng style for which there exi sts a one-to-one mapping between the
externall y observabl e states of the model and the states of some correspondi ng detai led reference model
such that themapping preservesthesequenceof statetransitionsbut not thei r preciseti mi ng. Thedegreeof
ti mi ng accuracy is undefined. See al so: cycle-approximate. (See10.3.4.)
B.5 argument: An expression in thecomma-separated li st bounded by theparenthesesin afunction cal l (or
macro or templ atei nstantiati on), also known asanactual argument. See al so: parameter. (C++ term)
B.6 attach: To associ ate an attri bute with an object by call ing member function add_attribute of class
sc_object. (See5.16.8.)
B.7 attribute(of a transaction): Datathat i s part of and carri ed wi th thetransacti onand isimpl emented as
a member of the transacti on object. These may i ncl ude attri butes i nherent i n the bus or protocol being
modeled, and attri butes that are arti facts of the si mulation model (a ti mestamp, for example). (See 11.1.2
and 14.7.)
B.8 automaticdeletion: A generi c payload extensi on marked for automati c deletion wil l bedeleted at the
end of thetransacti on li fetime, that is, when thetransaction referencecount reaches0. (See14.21.4.)
B.9 backward path: Thecall ing pathby which atarget or i nterconnect component makesi nterfacemethod
cal ls back in thedi recti on of another i nterconnect component or thei nitiator. (See10.4.)
B.10 baseclasssub-object: A sub-obj ect whosetypeis thebaseclasstypeof agi ven obj ect. See al so: sub-
object. (C++ term)
B.11 base protocol: A protocol traits class consisti ng of the generic payload and tl m_phase types, along
wi th an associated set of protocol rul es that together ensure maximal i nteroperabi li ty between transacti on-
level model s. (See15.2.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


567
Copyright 2012 IEEE. All rights reserved.
B.12 base-protocol-compl iant: Obeyi ngall therulesof theTLM-2.0 baseprotocol . (See9.1.)
B.13 bidi rectional i nterface: A TLM-1 transaction l evel interfacein which apai r of transaction objects, the
request and theresponse, arepassed i n oppositedi rections, each bei ng passed accordi ng to the rul es of the
unidirectional interface. For each transaction obj ect, the transacti on attri butes are stri ctl y read-only in the
period between thefi rst timing poi nt and theend of thetransaction li feti me. (See17.1.1.)
B.14 bindi ng, bound: An asymmetri cal associ ation created during elaborati on between aport or export on
the one hand and a channel (or another port or export) on the other. If a port (or export) is bound to a
channel, aprocess can makean interfacemethod call through the port to amethod defi ned in the channel .
Ports can be bound by name or by position. Exports can only be bound by name. See al so: I nterface
M ethod Cal l. (See4.1.3.)
B.15 bi t-sel ect: A class that referencesa single bit wi thi n a multipl e-bit data type or an i nstanceof such a
class. Bit-selects aredefi ned for each SystemC numeri c type and vector class. Bit-selectscorrespondi ng to
lvaluesand rvaluesof aparti cul ar typearedisti nct cl asses. (See7.2.5.)
B.16 bi t vector : A cl ass that i sderived fromclass sc_bv_base, or an instanceof such aclass. A bi t vector
impl ementsamultipl e-bi t datatype, whereeach bit i srepresented by the symbol 0 or 1. (See 7.1.)
B.17 bl ocking: Permi tted to cal l the wait method. A blocking function may consume si mulati on time or
perform a context switch and, therefore, shal l not be cal led from a method process. A blocki ng i nterface
definesonly blocking functions.
B.18 bl ocki ng transpor t inter face: A blocking i nterface of the TLM-2.0 standard that contains a single
method b_transport. Beware that there sti ll exi sts a blocking transport method named transport, part of
TLM-1. (See11.1.1.)
B.19 body: A compound statement immedi ately followi ng the parameter declarati ons and constructor
ini ti al izer (if any) of afuncti on or constructor, and contai ning thestatementsto beexecuted by thefunction.
(C++ term)
B.20 br i dge: A component connecting twosegmentsof acommunication network together. A busbridgei s
a device that connects two simi lar or dissimi lar memory-mapped buses together. See al so: adapter;
transaction bri dge; tr ansactor. (See10.4 and 14.21.3.)
B.21 buffer : An instance of class sc_buffer , which i sa primitivechannel deri ved fromcl ass sc_signal . A
buffer di ffers from a signal in that an event occurs on a buffer whenever a value i s written to the buffer,
regardless of whether the wri te causesa val uechange. An event onl y occurson a signal when thevalueof
thesi gnal changes. (See6.6.1.)
B.22 call : The termcal l is taken to mean that afuncti on i scal led ei ther directl y or i ndi rectl y by call ing an
intermediatefuncti on that call sthefuncti oni n question. (See3.1.3.)
B.23 cal ler : In a functi on call , the sequence of statements from which the given function i s cal led. The
referent of thetermmay beafuncti on, aprocess, or amodule. Thi sterm isused in preferenceto i ni ti ator to
refer to thecal ler of afuncti on asopposedto thei nitiator of atransacti on.
B.24 cal lee: In afuncti on call , thefuncti on that i scall ed by thecall er, or themodul ein whi ch that function
isdefi ned. Thereferent of theterm may beafunction or amodul e. Thi sterm isused i n preferenceto target
to refer to thefuncti on body asopposed to thetarget of atransaction.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


568
Copyright 2012 IEEE. All rights reserved.
B.25 cal lback: A member functi on overri dden wi thin acl ass in themodul ehi erarchy that is cal led back by
the kernel at certain fixed points during el aborati on and si mulation. The cal lback functions are
before_end_of_elaboration, end_of_elaboration, start_of_si mulation, and end_of_si mulation. (See4.4.)
B.26 channel : A cl ass that impl ementsoneor moreinterfaces or an i nstanceof such acl ass. A channel may
be a hi erarchical channel or a primi ti ve channel , or if neither of these, it i s strongl y recommended that a
channel at least be derived from class sc_obj ect. Channel s serve to encapsulate the definition of a
communication mechanismor protocol . (See3.1.4.)
B.27 chil d: An instance that is withi n a given module. Module A i s a chi l d of module B i f module A is
wi thi n moduleB. (See3.1.4and 5.16.1.)
B.28 cl ass template: A pattern for any number of classes whose defi ni ti ons depend on the templ ate
parameters. The compil er treats every member functi on of the cl ass as a function templ ate wi th the same
parameters as thecl ass templ ate. A function templ ateis itself apattern for any number of functions whose
defini ti onsdependon thetemplateparameters. (C++ term)
B.29 cl ock: An instanceof cl ass sc_clock, which i sapredefined primi ti vechannel that model sthebehavior
of a peri odi c digital cl ock si gnal . Al ternati vel y, a clock can be modeled as an instance of the cl ass
sc_signal<bool>. (See6.7.1.)
B.30 clocked thr ead process: A thread process that isresumed onl y on the occurrenceof a singleexpli ci t
clock edge. A clocked thread process is created usi ng the SC_CTHREAD macro. There are no dynamic
clocked threads. (See5.2.9 and5.2.12.)
B.31 combined inter faces: Pre-defined groups of core interfaces used to parameterize the socket cl asses.
There are four combined interfaces: thebl ocking and non-blocking forward and backward i nterfaces. (See
10.6 and 13.1.)
B.32 compl ete obj ect: An obj ect that i snot asub-object of any other object. If acompleteobj ect isof class
type, it i sal so cal led amost der i ved obj ect. (C++ term)
B.33 component: An i nstanceof aSystemC modul e. This standard recogni zes three ki nds of component;
theini ti ator, interconnect component, andtarget. (See10.4.)
B.34 concatenati on: An obj ect that references the bits within mul tipl e obj ects as i f they were part of a
singleaggregateobject. (See7.2.7.)
B.35 contai n: The i nverse rel ationshi p to wi thi n between two modul es. Module A contai ns module B if
moduleB iswi thi n moduleA. (See3.1.4.)
B.36 conveni ence socket: A socket cl ass, derived from tlm_i ni ti ator _socket or tlm_tar get_socket, that
implementssomeaddi ti onal functi onal ity and isprovided for convenience. Several conveni encesocketsare
provided as util ities. (See16.1.)
B.37 conver si on function: A member function of the form oper ator type_i d that specifies a conversi on
fromthetypeof thecl assto thetypetype_id. See al so: user-defined conversion. (C++ term)
B.38 copy-constr uctibl e type: A typeT for which T(t) i s equivalent to t and &t denotes the address of t.
This includesfundamental typesaswel l ascertai n cl asses. (C++ term)
B.39 core inter face: Oneof thespeci fi c transaction level interfaces defined i n thi s standard, i ncl udi ng the
blocking and non-bl ocki ng transport interface, the direct memory interface, and the debug transport
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


569
Copyright 2012 IEEE. All rights reserved.
interface. Each core interface is an i nter face pr oper . The core i nterfaces are disti nct from the generi c
payl oad API. (SeeClause9.)
B.40 custom-protocol-compl iant: Using the TLM-2.0 standard sockets (or cl asses deri ved from these)
speciali zed wi th atraits classother than tl m_base_protocol_types andusing theTLM-2.0 generic payl oad.
(See9.1.)
B.41 cycl e-accur ate: A model ing stylei n which i t i s possibleto predict thestateof themodel i n any gi ven
cycl eat theexternal boundary of themodel and thusto establ ish a one-to-onecorrespondence between the
states of the model and the external ly observabl e states of a corresponding RTL model i n each cycl e, but
which is not requi red to re-eval uate expl ici tly the state of the enti re model i n every cycl e or to represent
expl icitly the state of every boundary pin or internal register. This term i s only appl icabl e to model s that
haveanoti on of cycles. (See10.3.7.)
B.42 cycl e-approximate: A model for which there exi sts a one-to-one mapping between the external ly
observable states of the model and the states of some corresponding cycl e-accurate model such that the
mapping preserves the sequence of state transi ti ons but not thei r preci se timing. The degree of timing
accuracy i sundefined. Thi stermis onl y appli cableto model sthat haveanotion of cycles.
B.43 cycle count accurate, cycl e count accur ate at transaction boundar ies: A modeling stylein whi ch i t
is possible to establ ish a one-to-one correspondence between the states of the model and the externall y
observablestates of acorrespondi ng RTL model assampl ed at thetiming pointsmarking theboundaries of
a transaction. A cycle count accurate model i s not requi red to be cycl e-accurate i n every cycle, but it i s
required topredi ct accuratel y both thefuncti onal stateand thenumber of cyclesat certain key timing poi nts
asdefi ned by theboundari esof thetransactionsthrough which themodel communi cateswithother models.
B.44 data member : An object declared wi thi n aclass definition. A non-stati c datamember isasub-object
of thecl ass. A stati c datamember isnot asub-object of thecl assbut hasstati c storagedurati on. Outsi deof a
constructor or member functi on of the cl ass or of any deri ved cl ass, a data member can only be accessed
usi ngthedot . and arrow -> operators. (C++ term)
B.45 declar ati on: A C++ languageconstruct that i ntroducesanamei nto aC++ program and speci fi eshow
the C++ compil er is to i nterpret that name. Not all decl arations are definitions. For example, a cl ass
decl aration speci fi es thenameof theclassbut not theclassmembers, whil eafuncti on decl arati on speci fi es
thefuncti on parameters but not thefunction body. See al so: defini ti on. (C++ term)
B.46 defi nition: The compl etespecificati on of avari abl e, functi on, type, or templ ate. For exampl e, aclass
defini ti on speci fi es thecl ass name and the cl ass members, and a function defini ti on speci fi esthe function
parameters and thefunction body. See al so: decl aration. (C++ term)
B.47 del ta cycl e: A control loop wi thin thescheduler that consistsof oneevaluati onphasefol lowed by one
update phase. The delta cycle mechani sm serves to ensure the determini stic simulation of concurrent
processes by separati ng and al ternati ng the computati on (or evaluation) phase and the communicati on (or
update) phase. (See4.2.2.)
B.48 del ta noti fi cati on: A noti fi cati on created as the result of a call to functi on noti fy wi th a zero time
argument. Theevent i snoti fi edonedeltacycleafter thecall to function noti fy. (See4.2.1 and 5.10.6.)
B.49 delta notificati on phase: The control step wi thi n the schedul er duri ng which processes are made
runnabl eas aresult of del tanotificati ons. (See4.2.1.4.)
B.50 dur ing el abor ati on, duri ng simul ati on: The phrases duri ng el aborati on and duri ng si mul ati on are
used to indi catethat an acti on may or may not happen at thesetimes. Themeani ng of thesephrasesisclosel y
ti ed to thedefini ti on of theel aboration and simul ation cal lbacks. For example, anumber of acti onsthat are
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


570
Copyright 2012 IEEE. All rights reserved.
permi tted duri ng el aborati on areexpli ci tl y forbiddenfromtheend_of_elabor ation cal lback. (See3.1.4and
4.4.)
B.51 dynami c process: A process created fromtheend_of_el abor ati on cal lback or duri ngsi mulati on.
B.52 dynamic sensitivity: The set of events or time-outs that would cause a process to be resumed or
triggered, as created by the most recent cal l to the wait method (in the case of a thread process) or the
next_tr igger method (i nthecaseof amethod process). See al so: sensitivi ty. (See4.2.)
B.53 effective l ocal time: Thecurrent time within a temporall y decoupled i niti ator. effecti ve_l ocal_ti me=
sc_time_stamp() + l ocal_time_offset. (See11.1.3.1.)
B.54 elabor ation: The execution phase during which themodulehi erarchy i s created and ports arebound.
Theexecuti onof aC++ appl icati onconsists of elaborati onfoll owed by simul ation. (SeeClause4.)
B.55 err or: Anobligati onon thei mplementati onto generateadiagnosti c messageusing thereport-handl ing
mechanism(function report of classsc_repor t_handl er ) with aseveri ty of SC_ERROR. (See3.2.5.)
B.56 evaluati on phase: The control step withi n the scheduler duri ng which processes are executed. The
eval uation phase is complete when the set of runnable processes i s empty. See al so: delta cycle. (See
4.2.1.2.)
B.57 event: An obj ect of cl ass sc_event. An event provides the mechani sm for synchroni zati on between
processes. The noti fy method of cl ass sc_event causes an event to be notified at a specific poi nt in time.
(Thenotification of an event i sdistinct fromanobject of typesc_event. Theformer isadynami c occurrence
at auni quepoint in time, and thel atter is an obj ect that can benoti fi ed many times duri ng itsl ifeti me.) See
al so: noti fi cation. (See3.1.4, and 5.10.)
B.58 event expressi on: A li st of eventsor event lists, separated by ei ther operator& or operator|, and passed
asan argument to ei ther thewait or thenext_tr igger method. (See5.9.)
B.59 event fi nder : A member functi on of a port cl ass that returns an event wi thin a channel instance to
which theport i sbound. An event finder can onl y becal led when creating stati c sensitivi ty. (See5.7.)
B.60 event l ist: An object of typesc_event_and_li st or sc_event_or _li st that may bepassed asan argument
to member function wait or next_tr igger. (See5.8.)
B.61 excl usi on r ule: A rule of the base protocol that prevents a request or a response from being sent
through asocket i f therei salready arequest or aresponse(respecti vel y) in progressthrough that socket. The
baseprotocol has two exclusion rules, therequest exclusion rul eand theresponseexcl usi on rul e, whi ch act
independently of oneanother. (See15.2.6.)
B.62 expor t: An i nstanceof classsc_expor t. An export specifiesan i nterfaceprovidedby amodule. During
simul ation, aport forwardsmethod call s to thechannel to whi ch theexport wasbound. An export forwards
method call sdown and into amoduleinstance. (See3.1.4and 5.13.)
B.63 extensi on: A user-defined object added to and carried around wi th a generic payl oad transacti on
object, or a user-defined class that extends the set of val ues that are assi gnment compati bl e with the
tl m_phase type. An ignorable extensi on may be used wi th the base protocol, but a non-ignorabl e or
mandatory extension requi resthedefi niti on of anew protocol traitsclass. (See14.21.)
B.64 fi fo: An i nstance of cl ass sc_fifo, which i s aprimi ti ve channel that models a first-i n-fi rst-out buffer.
Al ternati vel y, afi fo can bemodel ed asamodul e. (See6.23.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


571
Copyright 2012 IEEE. All rights reserved.
B.65 fini te-precision fi xed-point type: A cl assthat i sderi ved from classsc_fxnum or an instanceof such a
class. A finite-precision fi xed-poi nt type represents a signed or unsigned fixed-point value at a precision
li mi ted onl y by its specifi ed wordl ength, i nteger word l ength, quantizati on mode, and overflow mode. (See
7.1.)
B.66 fini te-pr eci si on i nteger : A class that i s deri ved from class sc_signed, class sc_unsi gned, or an
instance of such a class. A fini te-preci si on i nteger represents a si gned or unsigned i nteger val ue at a
precision li mitedonly by i ts specified word length. (See7.1.)
B.67 for war d path: The call ing path by which an i ni ti ator or interconnect component makes i nterface
method call sforwardi n thedirection of another interconnect component or thetarget. (See10.4.)
B.68 gener i c payload: A specific set of transacti on attri butes and their semanti cs together defini ng a
transaction payload that may be used to achi eve a degree of interoperabil ity between l oosel y-timed and
approxi mately-ti med model s for components communi cating over a memory-mapped bus. The same
transaction class is used for all modeli ngstyl es. (SeeCl ause14.)
B.69 global quantum: Thedefault ti mequantum used by every quantumkeeper and temporall y decoupled
ini ti ator. The intent i s that all temporall y decoupled initiators should typicall y synchroni ze on integer
mul tipl es of theglobal quantum, or morefrequently on demand. (SeeClause12.)
B.70 hierar chi cal binding: Bi ndi ng asocket on achil d modul eto asocket on aparent module, or asocket
on a parent module to asocket on achil d module, passi ng transactions up or down the module hierarchy.
(See16.1.4.)
B.71 hier ar chi cal channel: A cl ass that isderi ved fromcl ass sc_module and that implementsoneor more
interfaces or, more informally, an i nstanceof such a class. A hierarchical channel i s used when a channel
requires itsown ports, processes, or modul ei nstances. See al so: channel ). (See3.1.4 and 5.2.23.)
B.72 hi er archical name: The unique name of an i nstance withi n the modul e hi erarchy. The hierarchi cal
nameis composed from the stri ng namesof theparent-chil d chai n of modulei nstancesstarting from atop-
level module and terminati ng wi th the stri ng name of the instance being named. The stri ng names are
concatenated andseparatedwi th thedot character. (See5.3.4and5.16.4.)
B.73 hop: Oneinitiator socket bound to onetarget socket. Thepath fromani nitiator to atarget may consist
of mul ti pl ehops, each hop connecti ng two adjacent components. Thenumber of hopsbetween an initiator
and atarget isal ways onegreater than thenumber of interconnect componentsal ongthat path. For example,
if an ini ti ator is connected directly to atarget with no intervening interconnect components, the number of
hops is one. (See10.4.)
B.74 i gnor able extension: A generic payl oad extension that may bei gnored by any component other than
the component that set the extension. An ignorabl e extensi on i s not requi red to be present. Ignorabl e
extensi ons arepermittedby thebaseprotocol. (See14.21.1.1.)
B.75 ignor abl e phase: A phase, created by the macro DECLARE_EXTENDED PHASE, that may be
ignored by any component that receivesthephaseandthat cannot demand aresponseof any kind. Ignorabl e
phasesarepermi tted by thebaseprotocol. (See15.2.5.)
B.76 i mmediate notificati on: A noti fi cation created as the result of a call to functi on wi th an empty
argument li st. Any process sensi ti veto theevent becomesrunnablei mmediately. (See4.2.1 and 5.10.6.)
B.77 i mplementation: A speci fi c concreteimplementation of thefull SystemCandTLM-2.0 cl assl ibraries,
only the publ ic shel l of whi ch need be exposed to theappli cation (for exampl e, partsmay be precompi led
and distri buted asobject codeby atool vendor). See al so: kernel. (See3.1.2.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


572
Copyright 2012 IEEE. All rights reserved.
B.78 i mplement: To createa channel that provides a definition for every pure vi rtual function declared in
theinterfacefromwhi ch it is derived. (See5.14.1.)
B.79 i mpli ci t conver si on: A C++ l anguage mechanism whereby a standard conversion or a user-defined
conversion is cal led impl icitly under certai n ci rcumstances. User-defined conversions are only appl ied
impl ici tly where they are unambi guous, and at most one user-defi ned conversion is appl ied impl icitly to a
given value. See al so: user-defined conversion. (C++ term)
B.80 i nitiali zation phase: The fi rst phase of the scheduler, during whi ch every process is executed once
until it suspendsor returns. (See4.2.1.1.)
B.81 ini ti alizer li st: The part of the C++ syntax for a constructor defini ti on that i s used to i ni ti alize base
class sub-obj ectsanddatamembers. (Related to theC++ term mem-i ni ti al i zer -l i st)
B.82 i ni ti ator : A modulethat can i nitiatetransacti ons. Thei nitiator i sresponsiblefor i ni ti alizing thestateof
the transacti on obj ect, and for del eting or reusing the transacti on obj ect at the end of the transaction's
li feti me. Ani ni ti ator is usuall y amaster and amaster isusually ani ni ti ator, but thetermi ni ti ator meansthat
acomponent can ini ti atetransactions, whereasthetermmaster means that acomponent cantakecontrol of a
bus. Inthecaseof theTLM-1 interfaces, theterm i ni ti ator asdefi ned heremay not bestri ctl y appli cable, so
thetermscal l er andcal l ee may beused instead for clari ty. (See10.4.)
B.83 i nitiator socket: A cl asscontaining aport for interfacemethodcal lson theforward path and anexport
for i nterfacemethod cal lson thebackward path. A socket overl oads theSystemCbinding operatorsto bind
both theport andtheexport. (See13.2.)
B.84 i nterconnect component: A module that accesses a transacti on object, but it does not act as an
ini ti ator or atarget wi th respect to that transaction. An i nterconnect component may or may not bepermi tted
to modi fy the attri butes of the transaction object, depending on the rules of the payload. An arbiter or a
router woul dtypicall y bemodeled asan i nterconnect component, thealternativebeing to model it asatarget
for onetransaction and ani ni ti ator for aseparatetransaction. (See10.4.)
B.85 instance: A particular caseof agi ven category. For example, amodul ei nstance i san obj ect of aclass
derived fromclasssc_module. Withi n thedefini ti on of thecorelanguage, an i nstance i stypi cal ly an object
of acl ass derivedfromclasssc_obj ect and hasauni quehierarchi cal name. (See3.1.4.)
B.86 instantiati on: Thecreati on of anew obj ect. For example, amodule instantiati on creates anew obj ect
of acl ass derivedfromclasssc_modul e. (See4.1.1.)
B.87 i nteger : A li mi ted-precision integer or afi nite-preci sion integer. (See7.2.1.)
B.88 i nterface: A class derived from cl ass sc_i nterface. An interface proper is an i nterface, and in the
object-oriented sense a channel is also an interface. However, a channel is not an i nterface proper. (See
3.1.4.)
B.89 I nter face M ethod Call (I M C): A cal l to an interface method. An interface method i s a member
functi on decl ared within an interface. TheIMC paradi gm providesal evel of i ndi rection between a method
cal l and the impl ementation of the method within a channel such that one channel can be substi tuted wi th
another without affecting thecal ler. (See4.1.3 and5.12.1.)
B.90 inter face proper: An abstract class derived from cl ass sc_i nterface but not derived from cl ass
sc_obj ect. An interface proper declares the set of methods to be i mplemented wi thin a channel and to be
cal led through a port. An i nterface proper contains pure virtual functi on declarations, but typi cal ly i t
contai nsno function definitionsand no datamembers. (See3.1.4 and5.14.1.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


573
Copyright 2012 IEEE. All rights reserved.
B.91 i nteroperabil ity: The abil ity of two or more transaction level model s f rom diverse sources to
exchange inf ormation usi ng the interfaces defi ned in this standard. The intent is that models that impl ement
common memory-mapped bus protocol s in the programmers view use case should be i nteroperabl e without
the need for expl ici t adapters. Furthermore, the intent i s to reduce the amount of engineering eff ort needed to
achi eve interoperabi li ty f or models of di vergent protocol s or use cases, although it is expected that adapters
wi ll be required i n general . (See Cl ause 9.)
B.92 inter oper abil ity layer : The subset of cl asses in this standard that are necessary f or i nteroperabi li ty.
The interoperabi li ty l ayer comprises the TLM-2.0 core i nterf aces, the ini ti ator and target sockets, the generi c
payl oad, tl m_global_quantum and tl m_phase. Closely related to the base protocol. (See Cl ause 9.)
B.93 ker nel : The core of any SystemC i mplementati on i ncl udi ng the underlyi ng elaborati on and si mulation
engi nes. The kernel honors the semantics defi ned by this standard but may also contain implementati on-
specif ic functionali ty outsi de the scope of thi s standard. See al so: implementation. (See Clause 4.)
B.94 l ifeti me (of an obj ect): The l if etime of an obj ect starts when storage i s all ocated and the constructor
cal l has completed, i f any. The l if etime of an object ends when storage is rel eased or immedi atel y before the
destructor i s call ed, if any. (C++ term)
B.95 l ifetime (of a tr ansacti on): The period of time that starts when the transaction becomes val id and ends
when the transaction becomes i nvali d. Because i t is possi bl e to pool or re-use transaction obj ects, the
li fetime of a transaction object may be l onger than the li fetime of the correspondi ng transacti on. For
exampl e, a transaction object coul d be a stack variable passed as an argument to multiple put call s of the
TLM-1 interf ace.
B.96 l imited-preci si on fixed-point type: A cl ass that i s deri ved from cl ass sc_fxnum_fast, or an instance
of such a cl ass. A li mited-preci si on fi xed-point type represents a si gned or unsi gned f ixed-point value at a
precision l imi ted by i ts underlying nati ve C++ f loating-poi nt representati on and i ts specif ied word length,
integer word length, quantizati on mode, and overf low mode. (See 7.1.)
B.97 li mi ted-precision i nteger : A cl ass that is deri ved f rom cl ass sc_i nt_base, class sc_uint_base, or an
instance of such a class. A l imi ted-preci si on i nteger represents a signed or unsi gned integer value at a
precision li mited by its underlying native C++ representati on and i ts speci fi ed word l ength. (See 7.1.)
B.98 local quantum: The amount of si mulati on ti me remaini ng before the i niti ator i s requi red to
synchronize. Typicall y, the local quantum equal s the current simulati on time subtracted f rom the next
largest i nteger multiple of the global quantum, but this calculati on can be overridden f or a given quantum
keeper. (See 16.2.)
B.99 local ti me offset: Time as measured rel ative to the most recent quantum boundary i n a temporall y
decoupled i ni ti ator. The timi ng annotation arguments to the b_tr anspor t and nb_transpor t methods are
local ti me of fsets. ef fecti ve_local _time = sc_time_stamp() + l ocal_ti me_of fset. (See 16.2.)
B.100 l ogi c vector : A cl ass that i s deri ved from cl ass sc_l v_base or an instance of such a class. A l ogi c
vector impl ements a multiple bit data type, where each bi t i s represented by a four-val ued logic symbol 0,
1, X, or Z. (See 7.1.)
B.101 loosel y-timed: A modeli ng style that represents mi nimal timi ng inf ormati on suf fi cient onl y to
support features necessary to boot an operati ng system and to manage mul ti pl e threads in the absence of
expl icit synchroni zati on between those threads. A loosel y-ti med model may include timer models and a
notional arbitrati on i nterval or execution sl ot length. Some users adopt the practice of i nserting random
del ays into l oosel y-ti med descripti ons in order to test the robustness of thei r protocols, but thi s practi ce does
not change the basi c characteri stics of the modeli ng style. (See 10.3.2.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


574
Copyright 2012 IEEE. All rights reserved.
B.102 l value: An object reference whose address can be taken. The left-hand operand of the buil t-
inassi gnment operator must be a non-const lvalue. (C++ term)
B.103 mandator y extension: A generi c payload extensi on that i s required to be present on every
transaction that i s sent through a socket of a given user-def ined protocol type. (See 14.21.1.2.)
B.104 master : This term has no precise technical def ini ti on in thi s standard, but it is used to mean a modul e
or port that can take control of a memory-mapped bus in order to initiate bus traf f ic, or a component that can
execute an autonomous software thread and thus ini tiate other system activity. General ly, a bus master
would be an initiator.
B.105 member function: A f unction decl ared withi n a cl ass def inition, excl udi ng f ri end f unctions. Outsi de
of a constructor or member function of the cl ass or of any derived class, a non-static member functi on can
only be accessed using the dot . and arrow -> operators. See al so: method. (C++ term)
B.106 memory manager : A user-def ined class that perf orms memory management f or a generic payload
transaction object. A memory manager must provide a free method, cal led when the reference count of the
transaction reaches 0. (See 14.5.)
B.107 method: A functi on that impl ements the behavior of a class. Thi s term i s synonymous wi th the C++
term member functi on. I n SystemC, the term method is used i n the context of an i nter face method cal l .
Throughout this standard, the term member functi on is used when defi ning C++ cl asses (for conformance to
the C++ standard), and the term method is used in more informal contexts and when discussing i nterf ace
method call s.
B.108 method process: A process that executes in the thread of the schedul er and is call ed (or triggered) by
the scheduler at ti mes determi ned by its sensitivity. An unspawned method process i s created usi ng the
SC_METHOD macro, a spawned method process by cal li ng the functi on sc_spawn. (See 5.2.9 and 5.2.10.)
B.109 modul e: A class that is derived from class sc_module or, more inf ormall y, an instance of such a
class. A SystemC appl ication i s composed of modules, each module i nstance representi ng a hi erarchical
boundary. A module can contain instances of ports, processes, primiti ve channel s, and other modul es. (See
3.1.4 and 5.2.)
B.110 module hier ar chy: The set of all i nstances created during el aboration and li nked together using the
mechanisms of module i nstanti ation, port instantiati on, primi ti ve channel i nstanti ati on, process instantiati on,
and port bi nding. The modul e hi erarchy i s a subset of the obj ect hi erarchy. (See 3.1.4 and Cl ause 4.)
B.111 multipor t: A port that may be bound to more than one channel or port instance. A multiport is used
when an appli cation wishes to bind a port to a set of addressable channels and the number of channels is not
known unti l elaborati on. (See 4.1.3 and 5.12.3.)
B.112 mul ti -socket: One of a fami ly of convenience sockets that can be bound to multiple sockets
bel ongi ng to other components. An i nitiator mul ti -socket can be bound to more than one target socket, and
more than one i ni ti ator socket can be bound to a single target multi-socket. When cal li ng interface methods
through multi-sockets, the destinations are di stingui shed using the subscript operator. (See 16.1.4.)
B.113 mutex: An instance of cl ass sc_mutex, which i s a predef ined channel that models a mutual exclusion
communication mechanism. (See 6.27.1.)
B.114 nb_transport: The nb_tr anspor t_fw and nb_tr ansport_bw methods. I n thi s document, the ital ici zed
term nb_transpor t i s used to describe both methods i n si tuati ons where there i s no need to disti ngui sh
between them. (See 11.1.2.4.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


575
Copyright 2012 IEEE. All rights reserved.
B.115 non-abstr act cl ass: A class that i s not an abstract cl ass. (C++ term)
B.116 non-blocki ng: Not permitted to cal l the wait method. A non-bl ocking f unction i s guaranteed to return
wi thout consuming simul ation ti me or perf ormi ng a context switch and, therefore, may be call ed from a
thread process or from a method process. A non-blocking interface defines only non-blocking functions.
B.117 non-bl ocking tr anspor t interface: A non-blocki ng i nterf ace of the TLM-2.0 standard. There a two
such interfaces, contai ni ng methods named nb_tr anspor t_fw and nb_tr anspor t_bw. (See 10.3.8.)
B.118 non-ignor abl e extension: A generic payload extension that, i f present, every component receiving
the transaction is obl iged to act on. (See 14.21.1.2.)
B.119 notificati on: The act of scheduli ng the occurrence of an event as performed by the noti fy method of
class sc_event. There are three kinds of notif icati on: i mmediate notif ication, delta noti fi cation, and ti med
notif i cati on. See al so: event. (See 4.2.1 and 5.10.6.)
B.120 notifi ed: An event i s said to be noti fi ed at the control step of the schedul er i n whi ch the event is
removed f rom the set of pending events and any processes that are currently sensiti ve to that event are made
runnabl e. I nformally, the event occur s precisel y at the point when it is notif ied. (See 4.2.)
B.121 numer ic type: A f inite-precision integer, a li mited-precision integer, a fi nite-preci si on f ixed-point
type, or a l imi ted-precision f ixed-poi nt type. (See 7.1.)
B.122 obj ect: A region of storage. Every obj ect has a type and a lif eti me. An obj ect created by a def ini tion
has a name, whereas an object created by a new expression is anonymous. (C++ term)
B.123 obj ect hi erarchy: The set of al l objects of class sc_obj ect. Each object has a unique hi erarchical
name. Obj ects that do not bel ong to the module hierarchy may be created and destroyed dynami call y during
simul ation. (See 3.1.4 and 5.16.1.)
B.124 occur rence: The noti fi cation of an event. Except i n the case of immedi ate notif ication, a call to the
noti fy method of class sc_event wi ll cause the event to occur in a later del ta cycle or at a l ater poi nt i n
simul ation ti me. Of a time-out: a ti me-out occur s when the specif ied ti me i nterval has el apsed. (See 5.10.1.)
B.125 opposite path: The path i n the opposi te di rection to a given path. For the f orward path, the opposite
path i s the forward return path or the backward path. For the backward path, the opposite path i s the forward
path or the backward return path. (See 10.4.)
B.126 over load: To create two or more functions wi th the same name decl ared in the same scope and that
dif fer i n the number or type of thei r parameters. (C++ term)
B.127 over r ide: To create a member f unction i n a deri ved cl ass has the same name and parameter l ist as a
member functi on i n a base cl ass. (C++ term)
B.128 par ameter : An obj ect declared as part of a functi on decl arati on or defini ti on (or macro defini ti on or
templ ate parameter), also known as a f ormal parameter. See al so: argument. (C++ term)
B.129 parent: The inverse relati onship to chi l d. Module A is the parent of modul e B if modul e B is a chi l d
of module A. (See 3.1.4 and 5.16.1.)
B.130 par t-sel ect: A class that ref erences a conti guous subset of bits wi thi n a mul ti pl e-bit data type or an
instance of such a class. Part-selects are def ined f or each SystemC numeric and vector cl ass. Part-selects
correspondi ng to l val ues and rvalues of a parti cul ar type are disti nct cl asses. (See 7.2.7.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


576
Copyright 2012 IEEE. All rights reserved.
B.131 paused: The state of simulation after the scheduler has been exited f ollowi ng a cal l to sc_pause.
B.132 payload event queue (PEQ): A cl ass that maintai ns a queue of SystemC event noti fi cations, where
each notif icati on carries an associ ated transacti on object. Transacti ons are put into the queue annotated wi th
a del ay, and each transaction pops out of the back of queue at the time it was put in plus the given del ay.
Usef ul when combini ng the non-blocking interface wi th the approximatel y-timed coding style. (See 16.3.)
B.133 pendi ng: The state of an event f or which a noti ficati on has been posted; that i s, the noti fy method has
been cal led, but the event has not yet been noti fi ed.
B.134 phase: A period i n the l if etime of a transaction. The phase i s passed as an argument to the non-
blocking transport method. Each phase transiti on is associated with a timi ng point. The ti mi ng point may be
del ayed by an amount gi ven by the time argument to nb_transpor t. (See 11.1.2.6.)
B.135 phase tr ansi ti on: A transiti on f rom one phase to another, where the phase is represented by the value
of the phase argument to the non-blocking transport method. Each cal l to nb_transpor t, and each return from
nb_transpor t wi th a return val ue of TLM_UPDATED, marks a phase transi ti on. The base protocol does not
permi t call s to nb_transpor t where the val ue of the phase argument is unchanged f rom the previous state.
(See 15.2.4.)
B.136 por t: A class that is deri ved from class sc_por t or, more informally, an instance of such a class. A
port i s the pri mary mechanism for al lowing communication across the boundary of a modul e. A port
specif ies an i nterf ace requi red by a module. During si mulati on, a port f orwards method call s made f rom a
process withi n a module to the channel to whi ch the port was bound when the modul e was i nstantiated. A
port f orwards method call s up and out of a modul e i nstance. (See 3.1.4 and 5.12.)
B.137 por tless channel access: Cal li ng the member functions of a channel di rectly and not through a port or
export. (See 5.12.1.)
B.138 pr imitive channel : A class that i s deri ved from class sc_pr im_channel and i mplements one or more
interfaces or, more inf ormall y, an instance of such a cl ass. A primitive channel has access to the update
phase of the scheduler but cannot contain ports, processes, or module instances. (See 3.1.4 and 5.15.)
B.139 process: A process i nstance belongs to an i mplementati on-def ined cl ass deri ved from class
sc_obj ect. Each process i nstance has an associ ated f unction that represents the behavi or of the process. A
process may be a static process, a dynami c process, a spawned process, or an unspawned process. The
process is the primary means of descri bing a computati on. See al so: dynamic process; spawned pr ocess;
static process; unspawned process. (See 3.1.4.)
B.140 process handl e: An obj ect of class sc_process_handle that provi des saf e access to an underl ying
spawned or unspawned process instance. A process handl e can be val id or i nval id. A process handle
continues to exist i n the i nvali d state even after the associ ated process instance has been destroyed. (See
3.1.4 and 5.6.)
B.141 programmers vi ew (PV ): The use case of the sof tware programmer who requi res a f uncti onal ly
accurate, l oosely-ti med model of the hardware pl atf orm f or booti ng an operati ng system and running
appl ication sof tware.
B.142 protocol tr aits cl ass: A class contai ning a typedef for the type of the transacti on object and the phase
type, which i s used to parameterize the combi ned i nterfaces, and ef fecti vel y def ines a uni que type f or a
protocol. (See 14.2.2 and 14.2.3.)
B.143 pr oxy class: A cl ass whose onl y purpose is to extend the readabi li ty of certai n statements that woul d
otherwi se be restricted by the semanti cs of C++. An example is to al low an sc_i nt variable to be used as if i t
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


577
Copyright 2012 IEEE. All rights reserved.
were a C++ array of bool . Proxy classes are onl y intended to be used for the temporary (unnamed) val ue
returned by a f uncti on. A proxy cl ass constructor shal l not be call ed expl icitly by an appl icati on to create a
named object. (See 7.2.5.)
B.144 quantum: I n temporal decoupli ng, the amount a process i s permitted to run ahead of the current
simul ation ti me. (See 10.3.2, 11.1.1.7, and Cl ause 12.)
B.145 quantum keeper : A util ity cl ass used to store the l ocal ti me off set from the current simulation time,
which it checks agai nst a local quantum. (See 16.2.)
B.146 request: For the base protocol, the stage duri ng the li f etime of a transaction when information i s
passed from the initiator to the target. I n eff ect, the request transports generi c payload attri butes f rom the
ini ti ator to the target, i ncluding the command, the address, and f or a write command, the data array. (The
transaction is actuall y passed by ref erence and the data array by poi nter.)
B.147 r esolved si gnal : An instance of cl ass sc_signal_resol ved or sc_signal_r v, which are signal channel s
that may be written to by more than one process, with confli cti ng values bei ng resolved wi thin the channel.
(See 6.13.1.)
B.148 response: For the base protocol, the stage during the l if etime of a transaction when information is
passed f rom the target back to the i ni tiator. In eff ect, the response transports generi c payload attri butes from
the target back to the initiator, incl uding the response status, and for a read command, the data array. (The
transaction is actuall y passed by ref erence and the data array by poi nter.)
B.149 r esume: To cause a thread or cl ocked thread process to conti nue execution starting with the
executable statement immediatel y f ol lowi ng the wait method at whi ch it was suspended, dependent on the
sensitivity of the process. (See 5.2.11.) Also, a member functi on of cl ass sc_process_handl e that cancels the
eff ect of a previ ous cal l to suspend. (See 5.6.6.1.)
B.150 return path: The control path by which the cal l stack of a set of interface method call s i s unwound
along either the forward path or the backward path. The return path for the forward path can carry
inf ormati on from target to ini tiator, and the return path for the backward path can carry informati on from
ini ti ator to target. (See 10.4.)
B.151 r value: A val ue that does not necessari ly have any storage or address. An rval ue of fundamental type
can only appear on the right-hand si de of an assignment. (C++ term)
B.152 schedul ed: The state of an event or of a process as a result of a call to the noti fy, next_tr igger or
wait methods. An event can be schedul ed to occur, or a process can be schedul ed to be tri ggered or resumed,
either in a l ater delta cycl e or at a l ater si mulati on time.
B.153 scheduler : The part of the kernel that control s simul ation and is thus concerned with advancing time,
making processes runnabl e as events are noti fied, executing processes, and updating primi ti ve channel s.
(See Clause 4.)
B.154 sensi tivi ty: The set of events or ti me-outs that would cause a process to be resumed or tri ggered.
Sensitivi ty make take the f orm of static sensitivity or dynamic sensitivity. (See 4.2.)
B.155 si gnal : An i nstance of cl ass sc_signal, whi ch i s a primiti ve channel intended to model relevant
aspects of the behavi or of a si mpl e wi re as appropriate f or digital hardware si mulation. (See 3.1.4 and 6.4.)
B.156 signature: The i nf ormati on about a f uncti on rel evant to overload resolution, such as the types of its
parameters and any qual if iers. (C++ term)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


578
Copyright 2012 IEEE. All rights reserved.
B.157 simple socket: One of a fami ly of convenience sockets that are simpl e to use because they al low
cal lback methods to be registered di rectly with the socket object rather than the socket having to be bound to
another object that impl ements the requi red i nterfaces. The simple target socket avoids the need for a target
to impl ement both blocking and non-blocking transport interfaces by provi di ng automati c conversi on
between the two. (See 16.1.2.)
B.158 si mulation: The execution phase that consi sts of the executi on of the schedul er together with the
executi on of user-def ined processes under the control of the scheduler. The executi on of a SystemC
appl icati on consists of elaborati on f ol lowed by si mulation. (See Clause 4.)
B.159 sl ave: Thi s term has no precise technical defi niti on in this standard, but it is used to mean a reactive
module or port on a memory-mapped bus that is abl e to respond to commands f rom bus masters, but i t is not
abl e itself to ini ti ate bus traf fi c. Generall y, a slave would be model ed as a target.
B.160 socket: See: ini ti ator socket; tar get socket.
B.161 spawned pr ocess: A process i nstance created by cal li ng the f uncti on sc_spawn. See al so: process.
(See 3.1.4 and 5.5.6.)
B.162 special ized port: A cl ass deri ved f rom templ ate class sc_por t that passes a particul ar type as the f irst
argument to template sc_por t, and whi ch provides convenience functi ons for accessi ng ports of that specif ic
type. (See 6.8.)
B.163 standar d er ror response: The behavior prescribed by thi s standard for a generic payload target that
is unable to execute a transacti on successfull y. A target shoul d either (1) executethe transaction successf ully
or (2) set the response status attribute to an error response or c) cal l the SystemC report handler. (See
14.17.1.)
B.164 statement: A specif ic category of C++ l anguage construct that i s executed in sequence, such as the i f
statement, swi tch statement, for statement, and r eturn statement. A C++ expressi on fol lowed by a semi col on
is also a statement. (C++ term)
B.165 static process: A process created duri ng the constructi on of the modul e hi erarchy or f rom the
before_end_of_elaboration cal lback.
B.166 static sensi ti vity: The set of events or ti me-outs that would cause a process to be resumed or
triggered, as created usi ng the data member sensitive of class sc_module (in the case of an unspawned
process) or usi ng class sc_spawn_options (i n the case of a spawned process). See al so: sensitivity;
spawned process; unspawned pr ocess. (See 4.2.)
B.167 sti cky extensi on: A generi c payload extensi on object that i s not deleted (either automati call y or
explici tl y) at the end of li fe of the transaction object, and thus remai ns with the transacti on object when it is
pool ed. Sti cky extensi ons are not deleted by the memory manager. (See 14.5.)
B.168 str ing name: A name passed as an argument to the constructor of an instance to provide an i denti ty
f or that obj ect within the module hierarchy. The stri ng names of i nstances having a common parent module
wi ll be uni que wi thin that module and that modul e only. See al so: hier archical name. (See 5.3 and 5.16.4.)
B.169 sub-obj ect: An object contained withi n another object. A sub-object of a cl ass may be a data member
of that cl ass or a base class sub-obj ect. (C++ term)
B.170 suspend: To cause a process to cease executi on by havi ng the associ ated functi on cal l wait. Also, a
member f unction of class sc_process_handle that causes a process to remain suspended and whose ef fect
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


579
Copyright 2012 IEEE. All rights reserved.
can be cancel led by call ing resume. Also, to cause a process to cease execution by cal li ng member f uncti on
suspend of a process handl e associated wi th the process itself . (See 5.6.6.1.)
B.171 synchr oni ze: To yield such that other processes may run, or when using temporal decoupli ng, to
yield and wait until the end of the current ti me quantum. (See 10.3.2.)
B.172 synchronizati on-on-demand: The action of a temporall y decoupled process when it yields control
back to the SystemC schedul er so that simul ation ti me may advance and other processes run i n addition to
the synchronization poi nts that may occur routinel y at the end of each quantum. (See 10.3.3.)
B.173 synchronous reset state: The state entered by a process instance when its reset si gnal becomes acti ve
or when sync_reset_on i s cal led. When in the synchronous reset state, a process i nstance is reset each ti me
it is resumed. (See 5.6.6.3.)
B.174 tagged socket: One of a fami ly of convenience sockets that add an int id tag to every i ncomi ng
interface method call i n order to identi fy the socket (or element of a multi-socket) through whi ch the
transaction arri ved. (See 16.1.3.4.)
B.175 target: A module that represents the fi nal desti nation of a transaction, abl e to respond to transacti ons
generated by an i ni ti ator, but not i tsel f able to i nitiate new transacti ons. For a write operation, data i s copied
f rom the i ni ti ator to one or more targets. For a read operati on, data is copi ed f rom one target to the i ni ti ator.
A target may read or modi fy the state of the transacti on object. I n the case of the TLM-1 interf aces, the term
tar get as def ined here may not be stri ctly appli cable, so the terms cal l er and cal l ee may be used i nstead for
clari ty. (See 10.4.)
B.176 tar get socket: A cl ass containi ng a port f or interface method call s on the backward path and an
export f or interface method call s on the forward path. A socket al so overl oads the SystemC binding
operators to bind both port and export. (See 10.4.)
B.177 temporal decoupli ng: The abili ty to all ow one or more i nitiators to run ahead of the current
simul ation ti me i n order to reduce context swi tchi ng and thus i ncrease simul ation speed. (See 10.3.2.)
B.178 terminated: The state of a thread or cl ocked thread process when the associated f uncti on executes to
compl eti on or executes a return statement and thus control returns to the kernel or after the process has been
kil led. Call ing f uncti on wait does not termi nate a thread process. See al so: clocked thread pr ocess; method
process; thr ead process. (See 5.2.11 and 5.6.5.)
B.179 thread process: A process that executes in i ts own thread and is cal led once only by the scheduler
during initiali zation. A thread process may be suspended by the execution of a wait method, i n which case it
wi ll be resumed under the control of the scheduler. An unspawned thread process is created usi ng the
SC_THREAD macro, a spawned thread process by cal ling the functi on sc_spawn. See al so: spawned
process; unspawned pr ocess. (See 5.2.9 and 5.2.11.)
B.180 time-out: The thing that causes a process to resume or tri gger as a result of a call to the wait or
next_tri gger method with a ti me-valued argument. The process that call ed the method wi ll resume or
trigger after the specif ic time has el apsed, unless i t has already resumed or tri ggered as a result of an event
bei ng noti fi ed. (See 4.2 and 4.2.1.)
B.181 ti med noti fi cation: A noti fi cati on created as the resul t of a call to function notif y wi th a non-zero
ti me argument. (See 4.2.1 and 5.10.6.)
B.182 timed notificati on phase: The control step wi thin the scheduler duri ng which processes are made
runnabl e as a result of ti med notif icati ons. (See 4.2.1.5.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


580
Copyright 2012 IEEE. All rights reserved.
B.183 ti mi ng annotati on: The sc_time argument to theb_tr anspor t and nb_transpor t methods. A timing
annotation is alocal timeoffset. Therecipi ent of atransaction i srequi red to behaveas if it had received the
transaction at effecti ve_l ocal_time= sc_ti me_stamp() + local_ti me_offset. (See11.1.2.12 and 11.1.3.)
B.184 timing poi nt: A significant ti mewithi n thel ifetimeof atransaction. A loosel y-timed transacti on has
two timi ng points correspondi ng to the cal l to and return fromb_tr anspor t. An approximately-timed base
protocol transaction has four timi ng points, each corresponding to aphasetransi tion.
B.185 TLM -1: The first major version of the OSCI Transaction Level Modeli ng standard. TLM-1 was
rel eased in 2005. (SeeClause9.)
B.186 T LM -2.0: The second maj or versi on of the OSCI Transaction Level Modeli ng standard. TLM-2.0
wasfirst released in 2008 andtheOSCI TLM-2.0 LRM wasreleased in 2009. (SeeClause9.)
B.187 TLM -2.0-compli ant i mplementation: An i mplementati on that provides all of the TLM-2.0 classes
descri bed i n thi s standard wi th the semanti cs described in thi s standard, i ncl udi ng both the TLM-2.0
interoperabi li ty layer and theTLM-2.0 uti li ti es. (See9.1.)
B.188 top-level module, top-l evel obj ect: A modul e or obj ect that is not i nstantiated withi n any other
moduleor process. Top-level modulesareei ther i nstantiated wi thin sc_mai n, or i n theabsenceof sc_mai n,
areidentified usi ngan impl ementation-speci fi c mechani sm. (See3.1.4and 5.16.1.)
B.189 traits cl ass: In C++ programmi ng, acl ass that contains definitions such as typedefs that areused to
speciali zethebehavior of apri mary class, typicall y by havi ng thetrai tsclasspassedasatemplateargument
to the pri mary class. The defaul t template parameter provides the defaul t trai ts for the primary cl ass. (See
14.2.2 and 14.2.3.)
B.190 transaction: An abstracti on for an interacti on or communi cation between two or more concurrent
processes. A transacti on carri es a set of attributes and i s bounded i n time, meani ng that the attributes are
only vali d withi n aspecific timewi ndow. Thetimi ng associated wi th thetransacti on isl imi ted to aspeci fi c
set of ti mi ng points, depending on thetypeof thetransaction. Processes may bepermitted to read or modify
attri butes of thetransaction, depending on theprotocol .
B.191 tr ansaction br idge: A component that acts as the target for an i ncomi ng transacti on and as the
ini ti ator for an outgoi ngtransaction, usuall y for thepurposeof modeli ng abusbridge. See al so: br idge. (See
10.4.)
B.192 tr ansacti on instance: A uni queinstanceof atransacti on. A transaction i nstanceisrepresented by one
transaction obj ect, but thesametransaction object may bere-used for several transaction instances.
B.193 transaction level (TL): Theabstracti on level at which communicati onbetween concurrent processes
is abstracted away from pin wi ggl ing to transacti ons. This term does not imply any parti cul ar l evel of
granul ari ty with respect to theabstraction of time, structure, or behavi or. (See10.2.)
B.194 transaction obj ect: Theobject that stores theattributesassociated with atransaction. Thetypeof the
transaction obj ect is passed asatemplateargument tothecoreinterfaces.
B.195 tr ansaction level model, tr ansacti on l evel model ing (TLM ): A model at the transaction level and
the act of creating such a model , respecti vel y. Transaction level models typicall y communi cate using
functi on call s, as opposed to the style of setti ng events on individual pins or nets as used by RTL model s.
(See10.2.)
B.196 tr ansactor : A modul e that connects a transacti on l evel interface to a pin l evel interface (i n the
general senseof theword i nter face) or that connects together two or moretransacti on l evel interfaces, often
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


581
Copyright 2012 IEEE. All rights reserved.
at dif ferent abstracti on l evels. In the typical case, the fi rst transaction level interface represents a memory-
mapped bus or other protocol, and the second interf ace represents the impl ementation of that protocol at a
lower abstracti on l evel . However, a single transactor may have mul ti ple transacti on l evel or pi n l evel
interf aces. See al so: adapter; br idge.
B.197 tr ansparent component: A interconnect component wi th the property that all i ncoming i nterf ace
method cal ls are propagated immedi atel y through the component without del ay and without modi fi cation to
the arguments or to the transaction obj ect (extensi ons excepted). The intent of a transparent component i s to
all ow checkers and monitors to pass i gnorabl e phases. (See 15.2.5.)
B.198 tr ansport inter face: The one and onl y bidirectional core interface i n TLM-1. The transport i nterf ace
passes a request transacti on object from cal ler to cal l ee, and i t returns a response transacti on object from
cal lee to cal ler. TLM-2.0 adds separate blocking and non-blocki ng transport interfaces. (See 10.3.8.)
B.199 tr igger : To cause the member functi on associated wi th a method process instance to be cal led by the
schedul er, dependent on its sensitivity. See al so: method process; sensitivity. (See 5.2.10.)
B.200 unidir ectional inter face: A TLM-1 transacti on level interface in whi ch the attributes of the
transacti on object are strictl y read-onl y in the period between the f irst ti mi ng point and the end of the
transaction l if etime. Eff ecti vel y, the i nf ormation represented by the transaction object is strictl y passed in
one di rection either from cal ler to cal lee or f rom call ee to cal ler. I n the case of void put(const T& t), the
f irst ti ming point is marked by the f unction cal l. I n the case of void get(T& t), the f irst timi ng poi nt is
marked by the return from the f unction. I n the case of T get(), stri ctly speaki ng there are two separate
transaction objects, and the return f rom the function marks the degenerate end-of-li fe of the f irst object and
the fi rst timi ng point of the second. (See 17.1.1.)
B.201 unspawned process: A process created by i nvoki ng one of the three macros SC_METHOD,
SC_THREAD, or SC_CTHREAD duri ng elaborati on. See al so: process. (See 3.1.4 and 4.1.2.)
B.202 untimed: A modeli ng style i n which there is no expli ci t mention of ti me or cycl es, but which i ncl udes
concurrency and sequencing of operati ons. In the absence of any expl icit notion of ti me as such, the
sequencing of operations across multiple concurrent threads must be accompli shed using synchronization
pri mitives such as events, mutexes, and bl ocki ng FI FOs. Some users adopt the practi ce of inserting random
del ays into untimed descriptions in order to test the robustness of thei r protocols, but this practice does not
change the basi c characteristi cs of the model ing style. (See 10.3.1.)
B.203 update phase: The control step within the schedul er duri ng whi ch the values of pri mitive channel s
are updated. The update phase consists of executi ng the update method for every pri mi ti ve channel that
cal led the request_update method during the i mmediately precedi ng evaluati on phase. (See 4.2.1.3.)
B.204 undefined: The absence of any obli gations on the implementati on. Where thi s standard states that a
behavior or a result is undefi ned, the impl ementation may or may not generate an error or a warning. (See
3.3.5.)
B.205 user : The creator of an appli cati on, as di stinct f rom an impl ementor, who creates an i mplementation.
A user may be a person or an automated process such as a computer program. (See 3.1.2.)
B.206 user-defined conver si on: Ei ther a conversion functi on or a non-expl icit constructor with exactly one
parameter. See al so: conver si on function; implicit conver sion. (C++ term)
B.207 util ities: A set of classes of the TLM-2.0 standard that are provided f or convenience only and are not
strictl y necessary to achieve interoperabi li ty between transaction-level model s. (See Cl ause 16.)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


582
Copyright 2012 IEEE. All rights reserved.
B.208 valid: The state of a process handl e, or of an object passed to or returned f rom a f uncti on by pointer or
by ref erence, duri ng any period i n whi ch the handl e or object is not del eted and its val ue or behavi or remains
accessibl e to the application. A process handl e i s val i d when it is associated with a process instance. (See
3.3.3 and 5.6.1.)
B.209 var iable-precision fixed-point type: Cl asses sc_fxval and sc_fxval_fast represent vari abl e-
precision fi xed-poi nt val ues that do not model overflow and quantizati on eff ects but are used as operand
types and return types by many f ixed-point operati ons. These types are not typi cal ly used directl y by an
appl icati on. (See 7.1.)
B.210 vector: See: bit vector ; logic vector . (See 7.1 and 8.5.)
B.211 war ning: An obl igation on the impl ementation to generate a diagnosti c message usi ng the report-
handl ing mechani sm (f uncti on report of class sc_repor t_handler) with a severi ty of SC_WARNING. (See
3.3.5.)
B.212 within: The rel ationshi p that exi sts between an instance and a module i f the constructor of the
instance i s call ed f rom the constructor of the modul e, and al so provi ded that the i nstance i s not wi thi n a
nested module. (See 3.1.4.)
B.213 yield: Return control to the SystemC schedul er. For a thread process, to yi el d is to call wait. For a
method process, to yi el d i s to return f rom the functi on.
583
Copyright 2011 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


Annex C
(informative)
Deprecated features
This annex contains a list of deprecated features. A depr ecated feature i s a feature that was present in
version 2.0.1 of the OSCI open source proof-of-concept SystemC implementation but is not part of this
standard. Deprecated features may or may not remain in theAccell eraSystemsIni ti ativeimpl ementation i n
thefuture. Theuser isstrongl y discouraged from using deprecated featuresbecauseanimpl ementation isnot
obli ged to support such features. An impl ementation may issue a warning on the first occurrence of each
deprecated featurebut isnot obliged to do so.
a) Functionssc_cycle and sc_initialize (Usesc_star t instead)
b) Cl ass sc_simcontext (Replaced by functions sc_delta_count, sc_is_r unning,
sc_get_top_level_obj ects, and sc_find_obj ect, and by member functi ons get_child_obj ects and
get_parent_obj ect)
c) Typesc_process_b (Replaced by cl ass sc_process_handle)
d) Function sc_get_cur r _process_handle (Replacedby function sc_get_curr ent_pr ocess_handle)
e) Member function notify_delayed of classsc_event (Usenotify(SC_ZERO_TI M E) instead)
f) Non-member function notify (Usemember functi onnotify of classsc_event instead)
g) Member functi on timed_out of classessc_module and sc_pr im_channel
h) oper ator , and oper ator << of class sc_module for positional port bi ndi ng(Useoper ator () instead)
i ) oper ator () of class sc_module for posi ti onal port bi ndi ng when call ed more than onceper modul e
instance(Usenamed port bi ndi ngi nstead)
j ) Constructorsof class sc_por t that bind theport at thetimeof construction of theport object
k) oper ator () of classsc_sensitive (Useoper ator << instead)
l) Cl asses sc_sensitive_pos and sc_sensitive_neg and the correspondi ng data members of class
sc_module (Usetheevent findersposand neg instead)
m) Member function end_module of classsc_module
n) Default ti meunitsand al l theassoci atedfunctionsandconstructors, including:
1) Function sc_simulation_time
2) Function sc_set_default_time_unit
3) Function sc_get_default_time_unit
4) Function sc_star t(double)
5) Constructor sc_clock(const char* , double, double, double, bool)
o) Member function trace of classes sc_obj ect, sc_signal, sc_clock, and sc_fifo (Use sc_trace
instead)
p) Member functi on add_tr ace of classessc_in and sc_inout (Usesc_trace instead)
q) Member function get_data_ref of classes sc_signal and sc_clock (Use member functi on read
instead)
r) Member function get_new_value of classsc_signal
s) Typedefssc_inout_cl k and sc_out_clk (Usesc_out<bool> instead)
t) Typedef sc_signal_out_if
u) Constant SC_DEFAULT_STACK_SIZE (Function set_stack_size isnot deprecated)
v) Constant SC_MAX_NUM_DELTA_CYCLES
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


584
Copyright 2012 IEEE. All rights reserved.
w) Constant SYSTEMC_VERSION (Function sc_version is not deprecated)
x) Support f or the wif and isdb trace fi le formats (The vcd trace fi le f ormat i s not deprecated)
y) Member f uncti on sc_set_vcd_time_unit of class vcd_trace_file
z) Function sc_trace_delta_cycles
aa) Function sc_tracef or writing enumerati on li terals to the trace f il e (Other sc_tracefuncti ons are not
deprecated)
ab) Type sc_bit (Use type bool instead)
ac) Macro SC_CTHREAD, except for the case where the second argument i s an event f inder, whi ch is
sti ll supported
ad) Gl obal and l ocal watchi ng f or clocked threads (Use functi on reset_signal_isinstead)
ae) The reporting mechanism based on i nteger ids and the corresponding member functi ons of cl ass
sc_report, namel y, register_id, get_message, is_suppressed, suppress_id, suppress_infos,
suppress_warnings, make_warnings_errors, and get_id. (Repl aced by a reporting mechani sm
usi ng string message types)
af) Util ity classes sc_string, sc_pvector, sc_plist, sc_phash, and sc_ppq
ag) Macro DECLARE_EXTENDED_PHASE (From TLM-2.0.1. Use
TLM_DECLARE_EXTENDED_PHASE instead)
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


585
Copyright 2012 IEEE. All rights reserved.
Annex D
(informative)
Changes between IEEE Std 1666-2005 and IEEE Std 1666-2011
This annex l ists the more signi fi cant changes between the above two versions of the SystemC standard and
also lists changes between the OSCI TLM-2.0 Language Ref erence Manual (versi on JA32) and thi s
standard.
a) New process control member f unctions by which processes can suspend, resume, reset, or ki ll other
processes or themselves (see 5.6.6).
Newtypesand functions:
sc_descendant_inclusion_info
sc_process_handle::suspend
sc_process_handle::resume
sc_process_handle::di sable
sc_process_handle::enable
sc_process_handle::sync_reset_on
sc_process_handle::sync_reset_of f
sc_process_handle::reset
sc_process_handle::reset_event
sc_process_handle::ki ll
sc_process_handle::throw_i t
sc_process_handle::is_unwi ndi ng
sc_i s_unwinding
sc_unwind_exception
b) Any kind of process can have any number of synchronous or asynchronous resets, ef fectively
unif yi ng thread and cl ocked thread processes (see 5.2.13).
Newandextendedobjects:
sc_module::reset_si gnal_i s
sc_module::async_reset_si gnal _is
sc_spawn_options::reset_signal_is
sc_spawn_options::async_reset_si gnal_i s
c) Simul ation can be paused, and there i s a functi on to get the current state of si mulati on (el aboration,
running, paused, stopped, and so forth) (see 4.5.2 and 4.5.8).
Newtypesand functions:
sc_pause
sc_status
sc_get_status
d) The addtion of a starvation poli cy to sc_start combi ned with new behavior f or sc_start in the case
of event starvation, al lowi ng more control when pausing and restarting si mulati on (see 4.3.4.2).
Newtypes:
sc_starvati on_poli cy
e) The defi nition of sc_delta_count has been ref ined to accommodate sc_start(0) and sc_pause (see
4.5.5).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


586
Copyright 2012 IEEE. All rights reserved.
f ) The defi ni ti on of immedi ate noti fi cation has been cl arif ied such that a process cannot make i tsel f
runnabl e as a result of an i mmediate notif icati on (see 4.2.1.2).
g) New functions to detect pending acti vity at the current ti me and at f uture ti mes (see 4.5.7).
Newfunctions:
sc_pendi ng_activity_at_current_ti me
sc_pendi ng_activity_at_f uture_time
sc_pendi ng_activity
sc_ti me_to_pending_activity
h) There i s a f uncti on to return the maximum value of simul ation ti me (see 5.11.4).
Newfunctions:
sc_max_ti me
i ) Event li sts, as passed to the functi ons wait and next_trigger, can be constructed as expl icit obj ects,
making it possi ble to create event l ists contai ning a parameterized or variable number of events (see
5.8).
Newtypes:
sc_event_and_l ist
sc_event_or_l ist
j) Events can be given hi erarchi cal names in the same way as sc_objectsand can be searched f or by
name (see 5.10 and 5.17).
Newfunctions:
sc_module::get_chil d_events
sc_process_handle::get_chil d_events
sc_object::get_chi ld_events
sc_event::name
sc_event::basename
sc_event::i n_hi erarchy
sc_event::get_parent_obj ect
sc_hierarchi cal _name_exists
sc_get_top_level _events
sc_f ind_event
k) There is a new operator< in class sc_process_handle so that uni que process handles can usefull y
be stored i n standard contai ners (see 5.6.5).
Newfunctions:
sc_process_handle::operator<
sc_process_handle::swap
l ) The def ini ti on of function terminated of cl ass sc_process_handle has changed such that
terminated remains true even after the handle has become i nval id (see 5.6.5).
m) A new uti lity class sc_vector makes it easy to construct vectors of modules, ports, exports, and
channel s and to bind vectors of ports (see 8.5).
Newtypesand functions:
sc_vector_base
sc_vector
sc_vector_assembl y
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


587
Copyright 2012 IEEE. All rights reserved.
sc_assemble_vector
n) A signal can now only be wri tten once per del ta cycle, and there is expli ci t control over whether a
signal can have one or many wri ters across dif ferent delta cycl es (see 6.3).
Newtypes, functions, and templateparameters:
sc_writer_pol icy
sc_signal _wri te_if ::get_wri ter_poli cy
WRITER_POLICY
o) The bind f uncti on of the standard port and socket classes has been made vi rtual (see 5.12.7 and
5.13.7).
p) sc_mutex and sc_semaphore are now derived from sc_object rather than from sc_prim_channel,
so they may be i nstanti ated dynamical ly (see 6.27 and 6.29).
q) There i s a new asynchronous version of the request_update method of the primitive channel cl ass
that can be cal led safely f rom operating system threads outside of the SystemC kernel (see 5.15.6).
Newfunctions:
sc_pri m_channel ::async_request_update
r) Many of the constructors to convert C++ buil d-i n types to SystemC f ixed-point val ues have been
made expli ci t, removi ng certai n cases of type ambigui ty in fi xed-poi nt expressions.
s) A verbosity argument has been added to SC_I NFO reports such that the appl icati on can suppress
reports exceeding a given verbosity level (see 8.2.4 and 8.3.5).
Newtypes, functions, and macros:
sc_verbosi ty
sc_report::get_verbosity
sc_report_handler::set_verbosi ty_level
sc_report_handler::get_verbosi ty_level
SC_REPORT_INFO_VERB
t) There i s a new namespace sc_unnamed, whi ch includes the Boost argument pl acehol ders _1, _2,
_3, ... and so f orth (see 5.5.6).
Newnamespace:
sc_unnamed
u) The version of the SystemC impl ementation is now avail abl e to the preprocessor usi ng a set of
macros, mirroring a f eature al ready present i n TLM-2.0 (see 8.6.5).
Newmacros:
I EEE_1666_SYSTEMC
SC_VERSION_MAJOR
SC_VERSION_MINOR
SC_VERSION_PATCH
and so f orth...
v) The TLM-2.0 impl ementation can now be accessed through the header "tlm" as wel l as "tl m.h"(see
10.8).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


588
Copyright 2012 IEEE. All rights reserved.
w) The terms "base-protocol -compli ant," "custom-protocol-compl iant," and "TLM-2.0-compl iant-
implementati on" have been def ined (see 9.1).
x) A new option attri bute has been added to the TLM-2.0 generic payload to al low the use of the full
set of generi c payload attri butes wi th the DMI and debug transport interface (see 14.8).
Newtypesand functions:
tl m_gp_opti on
tl m_generi c_payload::get_gp_opti on
tl m_generi c_payload::set_gp_opti on
y) There are a f ew mi nor TLM-2.0 base protocol changes, not expected to cause backward
compatibil ity problems. For TL M_I GNORE_COMMAND, the generi c payl oad data poi nter may be
null . Al so for TLM_I GNORE_COMMAND, the target is free to chose the val ue returned from the
transport_dbgmethod (see 11.3.4 and 14.11).
z) The macro DECLARE_EXTENDED_PHASE has been renamed to
TLM_DECLARE_EXTENDED_PHASE (see 15.1).
Newmacros:
TLM_DECLARE_EXTENDED_PHASE
aa) The permi tted values of macro TLM_I S_PRERELEASE have changed f rom FALSE or TRUE to 0
or 1 (see 10.8.3).
ab) The TLM-1 Message Passing Interface has been given a more f ul l and precise defi nition (see
Clause 17).
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


589
Copyright 2012 IEEE. All rights reserved.
I ndex
A
abstract class, glossary 566
abstraction level 415
accept delay 510
acquire 471, 472
adapter 467
b/nb conversion 526
bri dge 465
add_attri bute, member f uncti on
class sc_object 129
address al ignment 489, 490
address attribute 475, 476, 478
DMI 476
endi anness 489
overlappi ng 516
transport_dbg 451, 474
all ow_none 446
all ow_read 446
all ow_read_wri te 446
all ow_write 446
analysis port 558
and_reduce, reducti on operator 197
appl ication
def ini ti on 5
glossary 566
approxi mately-ti med 419
message sequence chart 434
PEQ 541
phase sequence 503
ti mi ng annotation 439, 514
ti mi ng parameters 510
argument, glossary 566
ari thmeti c mode
endi anness 488, 491
async_request_update, member function 587
class sc_pri m_channel 16
schedul ing al gorithm 17
async_reset_signal _is, member function
class sc_module 24, 46, 585
class sc_spawn_options 24, 63, 585
asynchronous message passi ng 546
attach
attri bute 129
glossary 566
attr_cl tn, member f uncti on
class sc_object 130
auto-extensi on 496
B
b_transport 426
base protocol 503
message sequence chart 428
re-entrant 514
simpl e socket 525
simpl e sockets 519
switching to nb_transport 516
ti mi ng annotation 514
b/nb conversion 526
backward path 421, 431, 433
base cl ass sub-object, glossary 566
base protocol
b_transport 514
causal ity 510
excl usi on rul e 510
fl ow control 511
guidelines 517
memory management 504
phase sequence 503
phase transiti ons 505
switchi ng between codi ng styl es 516
ti mi ng annotation 514
transaction orderi ng 515
basename, member f uncti on
class sc_event 97, 99, 586
class sc_object 126
base-protocol -compli ant 588
bef ore_end_of_elaboration, member functi on 24
class sc_clock 151
class sc_export 117
class sc_module 55
class sc_port 112
class sc_pri m_channel 123
BEGI N_REQ 500
BEGI N_RESP500
base protocol 504
begi n, member f unction
class sc_attr_cltn 133
class sc_f xcast_context 383
class sc_f xtype_context 381
class sc_length_context 377
class sc_vector 406
big-endian 489, 491
binary fi xed-poi nt representation 293
bind order 456
bind, member function
class sc_export 115
class sc_in 153
class sc_port 108
class sc_vector 406, 587
class si mpl e_ini ti ator_socket 525
class tl m_anal ysis_port 559
class tl m_base_i nitiator_socket 460
binding 463, 522, 534
export binding 14
glossary 567
hierarchi cal 460, 522, 534
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


590
Copyright 2012 IEEE. All rights reserved.
named binding 53
order 456
port bi ndi ng 14
posi ti onal binding 53
bit concatenati on
class sc_concatref 253
vectors 286
bit vector
def ini ti on 189
glossary 567
bit-select
def ini ti on 194
glossary 567
bit-select cl asses
f inite-precision integer types 244
fi xed-poi nt types 299, 367
introduction 194
li mi ted-precision integer types 217
vectors 277
blocking transport interface 426, 546
vs non_bl ocking 548
vs non-blocking 419
body, glossary 567
Boost, support f or the free C++ l ibrary 65
bound
glossary 567
port to channel 14
bri dge 423, 465, 467, 474, 495
buff er
def ini ti on 147
glossary 567
BUSWI DTH 460, 480, 488
byte enable array 475, 480
deep_copy_from 473
endi anness 487
update_ori ginal_from 473
byte enable length attribute 475, 481
byte enable poi nter attri bute 475, 480
byte order mode
endi anness 491
C
C++ header f il e 35
C++, rel ationshi p with SystemC 2
cal l
def ini ti on 5
glossary 567
cal lback 525, 543
from kernel 23
glossary 568
cal led from, defi nition 5
can, usage 5
cancel_all, member f unction
class get_with_peq 543
class sc_event_queue 188
cancel, member functi on
class sc_event 101
canonical signed digi t 199
cast_switch, member f unction
li mi ted-precision fi xed-poi nt cl asses 301
causal ity
and base protocol 510
channel
glossary 568
hierarchi cal 6
instance 110
interface proper 117
ordered set of channel i nstances 109
port bi ndi ng 54
pri mitive 6, 119
pure virtual functi ons 135
trace 153
chi ld
def ini ti on 6
get_chi ld_obj ects, member f uncti on 55
glossary 568
port bi ndi ng 15
class sc_pri m_channel 587
class templ ate, glossary 568
classes
sc_attr_base 131
sc_attr_cltn 133
sc_attri bute 132
sc_bigi nt 240
sc_biguint 242
sc_bind_proxy 37
sc_bitref _r 277
sc_buff er 147
sc_bv 273
sc_bv_base 262
sc_clock 149
sc_concatref 253
sc_concref 286
sc_concref _r 286
sc_context_begin 377, 380, 382, 383
sc_event 97
sc_event_and_expr 95
sc_event_and_l ist 92
sc_event_f inder 90
sc_event_f inder_t 90
sc_event_or_expr 95
sc_event_or_l ist 92
sc_event_queue 186
sc_event_queue_if 186
sc_export 113
sc_export_base 113, 114
sc_f if o 173
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


591
Copyright 2012 IEEE. All rights reserved.
sc_f if o_blocking_in_if 171
sc_f if o_i n 178
sc_f if o_i n_i f 171
sc_f if o_nonbl ocki ng_in_if 171
sc_f if o_out 179
sc_f if o_out_i f 172
sc_f ix 346
sc_f ix_fast 296, 352
sc_f ixed 358
sc_f ixed_f ast 296, 362
sc_f xcast_context 382
sc_f xcast_swi tch 381
sc_f xnum 295, 327
sc_f xnum_bitref 367
sc_f xnum_f ast 332
sc_f xnum_f ast_bitref 367
sc_f xnum_f ast_subref 369
sc_f xnum_subref 369
sc_f xtype_context 380
sc_f xtype_params 378
sc_f xval 337
sc_f xval_f ast 341
sc_generic_base 256
sc_in 152
sc_i n_resolved 164
sc_in_rv 168
sc_i n<bool> 153
sc_in<sc_dt::sc_logic> 153
sc_inout 156
sc_inout_resolved 165
sc_inout_rv 169
sc_int 213
sc_i nt_base 203
sc_int_bi tref 218
sc_int_bi tref _r 217
sc_i nt_subref 222
sc_i nt_subref_r 222
sc_i nterf ace 117
sc_length_context 377
sc_length_param 375
sc_l ogi c 257
sc_lv 275
sc_lv_base 267
sc_module 37
sc_module_name 57
sc_mutex 182
sc_mutex_if 182
sc_object 124
sc_out 160
sc_out_resolved 166
sc_out_rv 170
sc_pli st (deprecated) 584
sc_port_base 104
sc_ppq (deprecated) 584
sc_pri m_channel 16, 119
sc_process_handle 67
sc_pvector (deprecated) 584
sc_report 388
sc_report_handler 391
sc_semaphore 185
sc_semaphore_if 184
sc_sensitive 60
sc_sensitive_neg (deprecated) 583
sc_sensitive_pos (deprecated) 583
sc_signal 139
sc_signal _in_if 135
sc_signal _in_if <bool > 136
sc_signal _in_if <sc_logic> 136
sc_signal _inout_if 137
sc_signal _resol ved 161
sc_signal _rv 167
sc_signal _wri te_if 137
sc_signal <bool > 144
sc_signal <sc_logi c> 144
sc_signed 227
sc_signed_bitref 244
sc_signed_bitref _r 244
sc_signed_subref 248
sc_signed_subref _r 248
sc_simcontext (deprecated) 583
sc_spawn_options 61
sc_string (deprecated) 584
sc_subref 280
sc_subref _r 280
sc_switch 381
sc_time 101
sc_trace_fi le 385
sc_ufi x 295, 349
sc_ufi xed 295, 360
sc_ufi xed_fast 365
sc_uint 215
sc_uint_base 208
sc_uint_bi tref 218
sc_uint_bi tref _r 218
sc_ui nt_subref 222
sc_ui nt_subref_r 222
sc_unsi gned 234
sc_unsi gned_bi tref 245
sc_unsi gned_bi tref_r 244
sc_unsi gned_subref 248
sc_unsi gned_subref _r 248
sc_value_base 201
clear_extension 472, 497, 544
clock
class sc_clock 149
glossary 568
thread processes 45
clocked thread process
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


592
Copyright 2012 IEEE. All rights reserved.
arguments f or macros 42
glossary 568
introduction 43
reset_si gnal _i s, f uncti on 44
clone 473, 495
codi ng styl e 415, 416
combi ned i nterfaces 423, 455
command attri bute 475, 477
DMI 445
transport_dbg 451
complete obj ect
glossary 568
module name 59
compute_l ocal_quantum 454, 539
concat_clear_data, member f unction
class sc_val ue_base 202
concat_get_ctrl , member function
class sc_val ue_base 202
concat_get_data, member f uncti on
class sc_val ue_base 202
concat_get_ui nt64, member function
class sc_val ue_base 202
concat_length, member function
class sc_val ue_base 202
concat_set, member function
class sc_val ue_base 202
concat, functi on
integers 255
logic and vector types 289
overview 196
templ ate 292
concatenation
base type 196
bits 286
class sc_val ue_base 201
glossary 568
integer 253
introduction 196
const
SC_BIND_PROXY_NIL 37
SC_LOGIC_0 261
SC_LOGIC_1 261
SC_LOGIC_X 261
SC_LOGI C_Z 261
SC_ZERO_TIME 103
const_i terator, typedef 133
contai n
def ini ti on 6
glossary 568
convenience socket 419, 456
conversion function 568
endi anness 491
SystemC data types 192
conversion, b/nb 526
co-operative multitasking 17
copy_from 473, 495
copy-constructi ble type
glossary 568
sc_attri bute templ ate 132
core interf ace 413
co-routine semantics 17
custom-protocol-compl iant 588
cycl e-accurate 419
D
dagger symbol, usage 7
data array 475, 479
bri dge 495
deep_copy_from 473
destructor 474
DMI 445
endi anness 487, 488
transport_dbg 451
update_ori ginal _from 473
data l ength attribute 475, 480
endi anness 489
transport_dbg 451
data member, gl ossary 569
data poi nter attri bute 475, 479
transport_dbg 451
data transfer time 510
data type classes 189
data_read_event, member f uncti on
class sc_f if o 177
class sc_f ifo_out 180
class sc_fi fo_out_if 173
data_read, member functi on
class sc_f ifo_out 180
data_written_event, member f uncti on
class sc_f if o 177
class sc_f ifo_i n 179
class sc_fi fo_i n_i f 172
data_wri tten, member functi on
class sc_f ifo_i n 179
debug 552
debug transport i nterface 423, 450
decl aration, glossary 569
DECLARE_EXTENDED_PHASE 588
deep_copy_from 473, 495
def ault_event, member function
class sc_event_queue 188
class sc_in 153
class sc_inout 157
class sc_interface 60, 119
class sc_signal 142
def aul t_value, member f unction
class sc_f xcast_context 383
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


593
Copyright 2012 IEEE. All rights reserved.
class sc_f xtype_context 381
class sc_length_context 377
def ini ti on, glossary 569
del ay
approxi mately-timed 419, 510
base protocol 510
ti mi ng annotation 438
delta cycl e
class sc_signal _inout_if 138
def ini ti on 19
glossary 569
write 142
del ta notif icati on
cancel, functi on 100
def ini ti on 16
descri ption 18
glossary 569
notif y, function 100
del ta notif icati on phase
glossary 569
overview 18
deprecated features
class sc_phash 584
class sc_pli st 584
class sc_ppq 584
class sc_pvector 584
class sc_sensitive_neg 583
class sc_sensitive_pos 583
class sc_sim_context 583
class sc_string 584
sc_bit, type 584
sc_cycl e, f uncti on 583
SC_DEFAULT_STACK_SIZE, const 583
sc_get_curr_process, function 583
sc_get_def aul t_ti me_uni t, functi on 583
sc_ini ti al ize, f unction 583
sc_inout_clk, typedef 583
SC_MAX_NUM_DELTA_CYCLES, const
583
sc_out_cl k, typedef 583
sc_process_b, type 583
sc_set_def aul t_ti me_unit, function 583
sc_set_vcd_ti me_unit, member function 584
sc_signal_out_if , typedef 583
sc_start(double), functi on 583
sc_trace_delta_cycl es, functi on 584
set_si mulati on_ti me, function 583
derived from, defi nition 5
direct memory interface 423, 442
disabl e, member f unction
class sc_process_handle 79, 585
disabl ed, usage 7
DMI 423, 442
latency 448
overlapping regions 447
temporal decoupl ing 449
vs transport 449
DMI all owed attribute 450, 474, 482
modif icati on at target 476
DMI descri ptor 445
DMI hint 450, 482
modif icati on at target 476
DMI _ACCESS_NONE 447
DMI_ACCESS_READ 446
DMI_ACCESS_READ_WRI TE 446
DMI_ACCESS_WRI TE 446
dmi_data 444
dont_initiali ze, member f uncti on
class sc_module 24, 48
class sc_spawn_options 63
semantics 17
doubl e, member f uncti on
class sc_f xval 340
draft versi on 413
dump, member f unction
class sc_f if o 177
class sc_object 127
class sc_signal 143
duri ng elaborati on
def ini ti on 7
glossary 569
duri ng simul ation
def ini ti on 7
glossary 569
duty_cycle, member functi on
class sc_clock 151
dynami c process
class sc_process_handle 67
def ini ti on 6
descri ption 563
dynami c, member f unction 72
glossary 570
parent 64
dynami c sensitivi ty
def ini ti on 16
glossary 570
next_tri gger, function 43, 50
wait, function 52
dynami c, member f unction
class sc_process_handle 72
dynami c, spawned process
sc_spawn, functi on 64
E
early completi on
base protocol 504
eff ective l ocal time 439, 514
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


594
Copyright 2012 IEEE. All rights reserved.
elaboration 12
cal lback f uncti ons 23
glossary 570
instanti ation 12
keeping track of module hierarchy 58
port bi ndi ng 15
port i nstantiati on 107
running 20
sc_main, functi on 21
sc_set_time_resoluti on, f unction 103
simul ation ti me resolution 15
elem_type, typedef 133
ell ipsis, usage 7
enable, member functi on
class sc_process_handle 80, 585
end_of_elaborati on, member f uncti on 25
class sc_export 117
class sc_in 153
class sc_in_resolved 165
class sc_in_rv 169
class sc_inout 158
class sc_inout_resolved 166
class sc_inout_rv 170
class sc_module 55
class sc_port 112
class sc_pri m_channel 123
size of socket 534
end_of_simul ation, member function 27
class sc_export 117
class sc_module 55
class sc_port 112
class sc_pri m_channel 123
END_REQ 434, 500
base protocol 504
END_RESP 500
base protocol 504
end, member f uncti on
class sc_attr_cltn 134
class sc_f xcast_context 383
class sc_f xtype_context 381
class sc_length_context 377
class sc_vector 406
endi anness 487
conversion functions 491
hel per functi ons 490
enumeration
sc_curr_proc_kind_return 68
sc_descendant_inclusion_info 68, 585
sc_f mt 303
sc_logi c_value_t 257
sc_numrep 199, 383
sc_o_mode 301
sc_port_poli cy 104
sc_q_mode 301
sc_severi ty 388, 389
sc_starvati on_poli cy 20, 585
sc_status 28
sc_stop_mode 27
sc_time_uni t 101
sc_verbosi ty 388, 587
sc_writer_pol icy 137
tl m_gp_opti on 468, 588
error
def ini ti on 11
glossary 570
eval uation phase
def ini ti on 17
glossary 570
sc_spawn, functi on 64
sc_stop, f unction 30
update, functi on 122
event
def ini ti on 6, 97
glossary 570
simul ation 16
event expressi on
glossary 570
event f inder
class sc_f ifo_i n 179
class sc_f ifo_out 180
class sc_in 153, 156
class sc_inout 157
class sc_inout<bool> 160
class sc_inout<sc_dt::sc_logic> 160
class sc_sensitive 61
clocked thread process 45
descri ption 90
glossary 570
event l ist
class sc_event 101
class sc_event_and_expr 95
class sc_event_and_l ist 92
class sc_event_or_expr 95
class sc_event_or_list 92
glossary 570
event, member f unction
class sc_in 153
class sc_inout 157
class sc_signal 142
class sc_signal _in_if 135
exampl e
anal ysis port 560
attri butes 485
b_transport 440, 515
bind 463
byte enable 486
excl usi on rul es 513
extension 497
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


595
Copyright 2012 IEEE. All rights reserved.
generi c payload 485
get_direct_mem_ptr 447
hierarhi cal binding 535
instance-specifi c extension 545
multi-socket 535
nb_transport 440
protocol 498
quantum keeper 539
reentrancy 515
response status 485
simpl e socket 528
synchronization-on-demand 440
ti mi ng annotation 513
TLM_DECLARE_EXTENDED_PHASE 501
tl m_ini ti ator_socket 461
tl m_target_socket 461
traits class 498
excl usion rul e 510
executi on stack 44, 49
export
class sc_export 113
def ini ti on 5
glossary 570
export binding 14
extensi on
array 495, 496
auto-deleti on 496
DMI 442, 445
ignorable 466, 484, 494, 502, 516
instance-speci fi c 544
interoperabi li ty 465
mandatory 494, 574
non-ignorable 575
object 495
pointer 496
response status 484
transport_dbg 450
F
fi fo
class sc_f if o 173
glossary 570
interf aces 136
fi le
header f il es 35
trace fi le 386
f inite-preci sion f ixed-point type
def ini ti on 189
glossary 571
f inite-precision i nteger
def ini ti on 189
glossary 571
overview 171
typedef 227
f ixed-poi nt type 293
context obj ect 194
def ini ti on 189
fl ow control 511
f orward path 422, 431, 437
DMI 427
nb_transport 431
sockets 456
f ree
tl m_extension_base 495, 496
tl m_mm_i nterf ace 471, 472, 496
f ree_all _extensions 473
f rom_hostendian 491
G
generi c payload 413, 465, 469
attri butes 474
base protocol 503
DMI 445
DMI hint 450
endi anness 487
extensi ons 465
guidelines 517
instance-specif ic 544
memory 470
standard error response 484
transport_dbg 451
get 546, 552
tl m_global_quantum 454
get_address 478
get_attribute, member functi on
class sc_object 129
get_base_export 461
get_base_port 461
get_bus_width 460
get_byte_enabl e_l ength 481
get_chi ld_events, member function
class sc_module 55, 586
class sc_object 128, 586
class sc_process_handle 71, 586
get_chi ld_obj ects, member f uncti on
class sc_module 55
class sc_object 128
class sc_process_handle 71
return val ue 10
get_command 477
get_current_ti me 540
get_data_l ength 480
get_data_ptr 479
get_direct_mem_ptr 444, 446, 447
DMI hint 450
memory management 472
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


596
Copyright 2012 IEEE. All rights reserved.
payl oad attributes 475
simpl e sockets 519, 526
get_dmi_ptr 446
get_el ements, member f unction
class sc_vector_base 406
get_end_address 447
get_event 543
get_extension 496, 544
get_global _quantum 540
get_gp_opti on, member f uncti on
class tl m_generi c payload 476
class tlm_generic_payload 588
get_granted_access 446
get_host_endi anness 491
get_interface, member f uncti on
class sc_export 117
class sc_port 112
get_local _time 540
get_next_transacti on 542
get_parent_obj ect, member f uncti on
class sc_event 100, 586
class sc_object 128
class sc_process_handle 72
return val ue 9
get_phase 500
get_process_object, member functi on
class sc_process_handle 68, 72
return val ue 9
get_read_l atency 448
get_ref_count 471, 472
get_response_status 483
get_response_string 483
get_start_address 447
get_streaming_width 482
get_val ue, member f uncti on
class sc_semaphore 186
get_verbosity_l evel, member f unction
class sc_report_handler 396, 587
get_verbosity, member f unction
class sc_report 390, 587
get_wri te_latency 448
get_wri ter_poli cy, member f uncti on
class sc_signal 142
class sc_signal _inout_if 138
class sc_signal _wri te_if 587
global quantum 417, 453
H
has_host_endianness 491
has_mm 471, 473
header f ile 424
global quantum 453
instance-specifi c extension 544
multi-socket 532
passthrough_target_socket.h 525
PEQ 542
quantum keeper 537
simpl e socket 525
simpl e_ini ti ator_socket.h 525
simpl e_target_socket.h 525
tagged simpl e socket 529
hel per functi on
endi anness 490
hierarchi cal bi ndi ng 461, 522, 534
hierarchi cal channel
class sc_event_queue 186
class sc_object 125
def ini ti on 6
glossary 571
hierarchi cal name
class sc_module_name 57
descri ption 126
glossary 571
hop 422
phase argument 432
phase transiti ons 505
TLM_COMPLETED 504
host_has_l ittl e_endi anness 491
host-endian 488, 491
I
ID, of extension 495
I EEE_1666_SYSTEMC, macro 411, 587
ignorable
extension 442, 450, 466, 484, 494, 502, 516
phase 433, 500, 502, 503, 506, 508
immedi ate notif ication
cancel, functi on 100
def ini ti on 16
glossary 571
noti fy, function 100
impl ement
glossary 572
interf ace 117
update, functi on 142
impl ementation
def ini ti on 5
glossary 571
impl ementation-def ined, defini ti on 7
impl ici t conversion, gl ossary 572
in_hierarchy, member f uncti on
class sc_event 99, 586
inc, tl m_quantumkeeper 540
ini t, member f uncti on
class sc_vector 403
ini ti al izati on phase
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


597
Copyright 2012 IEEE. All rights reserved.
dont_initiali ze, f uncti on 48, 63
glossary 572
overview 17
ini ti al ize, member function
class sc_inout 157
ini ti al izer li st, glossary 572
ini ti ation interval 510
ini ti ator 420
base protocol gui del ines 517
DMI access 447
DMI hint 450
memory management 445, 470
rol e 476
socket 456
sync 433
ti mi ng annotation 438
transaction re-use 445
ini ti ator socket 422
instance
tl m_global _quantum 454
instance, glossary 572
instance-specifi c extension 544
instanti ation
duri ng elaboration 12
glossary 572
int_type, typedef 203
int64, typedef 203
integer concatenation
class sc_concatref 253
class sc_val ue_base 201
integer part-select obj ects 225
integer, gl ossary 572
interconnect 420
address attribute 475
address translati on 447
b_transport 427
base protocol gui del ines 520
bri dge 467
byte enable 481
DMI 444
DMI address space 447
DMI and side-eff ects 449
DMI hint 475
ignorable phase 508
memory management 471
pipeli ni ng 511
response status attri bute 483
rol e 476
TLM_I GNORE_COMMAND 478
transparent component 509
transport_dbg 451
interface
class sc_interface 117
def ini ti on 5
glossary 572
I nterf ace Method Cal l (I MC)
class sc_module 39
class sc_port 104
glossary 572
port and export bi ndi ng 15
interf ace proper
class sc_fi fo_i n_i f 171
class sc_fi fo_out_if 172
class sc_interface 117
class sc_mutex_if 182
class sc_port 105
class sc_semaphore_if 184
class sc_signal _in_if 135
class sc_signal _inout_if 137
def ini ti on 5
glossary 572
interoperabi li ty
base protocol 502
endi anness 487
extensi ons 465
generi c payload 465
interf aces 521
layer 413
phases 500
sockets 423
invali d, process handle 67
invali date_direct_mem_ptr 448
simpl e socket 526
is_01, member f unction
bit concatenati on classes 290
bit-select cl asses 279
class sc_bv_base 265
class sc_l ogi c 260
class sc_l v_base 271
part-sel ect cl asses 284
is_dmi_all owed 482
is_neg, member f uncti on
f ixed-poi nt classes 302
is_none_al lowed 446
is_read 478
is_read_all owed 446
is_read_write_al lowed 446
is_reset, member function
class sc_unwind_exception 82
is_response_error 483
is_response_ok 483
is_unwinding, member function
class sc_process_handle 83, 585
is_wri te 478
is_write_all owed 446
is_zero, member f unction
f ixed-poi nt classes 302
ISS 418
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


598
Copyright 2012 IEEE. All rights reserved.
iterator
attri butes 133
typedef 133
iwl, member functi on
class sc_f xtype_params 379
li mi ted-precision fi xed-poi nt classes 301
K
kernel
cal lbacks 23
elaborati on and simul ation 12
glossary 573
triggeri ng method process 43
kil l, member f uncti on
class sc_process_handle 81, 585
kil l, terminati ng a method process 43
kind 460, 462
returning sc_cthread_process 44
returning sc_method_process 43
returning sc_thread_process 44
kind, member function
class sc_buff er 148
class sc_clock 151
class sc_event_queue 187
class sc_export 114
class sc_f if o 177
class sc_f if o_i n 179
class sc_fi fo_out 180
class sc_in 153
class sc_in_resolved 165
class sc_in_rv 169
class sc_inout 157
class sc_inout_resolved 166
class sc_inout_rv 170
class sc_module 39
class sc_object 126
class sc_out 161
class sc_out_resol ved 167
class sc_out_rv 171
class sc_port 107
class sc_pri m_channel 121
class sc_semaphore 186
class sc_signal 143
class sc_signal _resol ved 163
class sc_signal _rv 168
L
latency
approxi mately-ti med 510
BUSWIDTH 480
DMI 442, 448
least si gni fi cant 293
len, member function
class sc_length_param 376
length context cl asses
class sc_f xtype_context 380
class sc_f xtype_params 378
class sc_length_context 377
class sc_length_param 375
introduction 193
length, member functi on
bit-select cl asses 221, 248, 253
class sc_bv_base 267
class sc_concatref 256
class sc_concref 292
class sc_generic_base 256
class sc_i nt_base 208
class sc_l v_base 273
class sc_signed 234
class sc_unsi gned 240
part-sel ect cl asses 226, 286
li fetime 421, 432, 470, 472, 484, 492, 505, 506
glossary 573
of objects 8
li mi ted vari abl e-precision fi xed-poi nt type
def ini ti on 189
li mi ted-precision fi xed-poi nt type
def ini ti on 189
glossary 574
li mi ted-precision integer
def ini ti on 189
glossary 573
li ttle 491
li ttle-endian 489, 491
local time 439, 514, 539
lock, member function
class sc_mutex 183
logi c vector
def ini ti on 189
glossary 574
loosel y-ti med 417, 418
b_transport 426
global quantum 453
switchi ng between codi ng styl es 516
ti mi ng annotation 439
lrotate, member functi on
class sc_bv_base 266
class sc_concref 290
class sc_l v_base 271
part-sel ect cl asses 285
LSB 487
lvalue, glossary 574
M
macros
DECLARE_EXTENDED_PHASE 588
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


599
Copyright 2012 IEEE. All rights reserved.
I EEE_1666_SYSTEMC 411, 587
sc_assert 394
sc_bind 65
SC_COPYRI GHT 411
sc_cref 65
SC_CTHREAD 39, 41
SC_CTOR 39, 40, 58
SC_DEFAULT_FATAL_ACTIONS 393
SC_DEFAULT_INFO_ACTIONS 393
SC_DEFAULT_WARNI NG_ACTI ONS 393
SC_FORK 66
SC_HAS_PROCESS39, 41
SC_IS_PRERELEASE 411
SC_JOI N 66
SC_METHOD 14, 39, 41
SC_MODULE 39, 40
sc_ref 65
SC_REPORT_ERROR 394
SC_REPORT_FATAL 394
SC_REPORT_INFO 394
SC_REPORT_INFO_VERB 394
SC_REPORT_WARNING 394
SC_THREAD 14, 39, 41
SC_VERSION 411
SC_VERSION_MAJOR 411, 587
SC_VERSION_MINOR 411, 587
SC_VERSION_ORIGI NATOR 411
SC_VERSION_PATCH 411, 587
SC_VERSION_PRERELEASE 411
SC_VERSION_RELEASE_DATE 411
TLM_COPYRI GHT 424
TLM_DECLARE_EXTENDED_PHASE 588
TLM_I S_PRERELEASE 424, 588
TLM_VERSI ON 424
TLM_VERSI ON_MAJOR 424
TLM_VERSI ON_MI NOR 424
TLM_VERSI ON_ORIGINATOR 424
TLM_VERSI ON_PATCH 424
TLM_VERSI ON_PRERELEASE 424
TLM_VERSI ON_RELEASE_DATE 424
mall oc 471
mandatory extension 494, 574
max_num_extensi ons 496
may, usage 5
member functi ons
glossary 574
process control 86
memcpy 479
memory management
extensions 495, 496
generi c payload 470, 474
get_direct_mem_ptr 473
hops 504
transport_dbg 473
memory-mapped bus 413, 426, 465, 484, 502
message passing
asynchronous 546
synchronous 546
message sequence chart
approxi mately-ti med 510
b/nb adapter 527
blocki ng transport 428
early completi on 436
ignorable phase 509
nb/b adapter 526
quantum 429
temporal decoupl ing 428
ti mi ng point 434
usi ng the return path 435
method process
arguments for macros 42
glossary 574
spawn_method, f unction 63
method, gl ossary 574
module
class sc_module 37
def ini ti on 5
glossary 574
module hierarchy
abnormal usage 107
cal lbacks 24
class sc_pri m_channel 121
def ini ti on 6
elaborati on 12, 58
glossary 574
most signif icant 293
MSB 293
multi_passthrough_initiator_socket 532
multi_passthrough_target_socket 532
multiport
def ini ti on 15
event f inder 90
glossary 574
port pol icy 106
posi ti onal port bi ndi ng 53
multi-socket 461, 531, 532, 536
multitasking 17
mutex
class sc_mutex 182
glossary 574
N
n_bi ts, member functi on
class sc_f xtype_params 379
li mi ted-precision fi xed-poi nt cl asses 301
name, member f unction
class sc_attr_base 132
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


600
Copyright 2012 IEEE. All rights reserved.
class sc_event 99, 586
class sc_object 126
class sc_process_handle 71
namespace 423
sc_core 10, 20
sc_dt 10, 189
sc_unnamed 10, 587
tl m 10
tl m_uti ls 10
usage 10
nand_reduce, reduction operator 197
nb_get 546, 552
nb_peek 546, 552
nb_poke 552
nb_put 546, 552
nb_read, member functi on
class sc_f if o 175
class sc_f if o_i n 179
class sc_f if o_i n_i f 172
nb_transport 431
base protocol 503
cal led from b_transport 427
ignorable phase 508
memory management 471
phase argument 432
phase transiti ons 506
simpl e socket 525
simpl e sockets 519
switchi ng to b_transport 516
ti mi ng annotation 439, 514
nb_transport_bw 431
nb_transport_fw 431
nb_wri te, member f unction
class sc_f if o 176
class sc_fi fo_out 180
class sc_fi fo_out_if 173
need_sync 540
negedge_event, member f uncti on
class sc_signal 146
class sc_si gnal _in_if 137
negedge, member f uncti on
class sc_signal 146
class sc_si gnal _in_if 137
next_tri gger, member function
class sc_module 17, 50, 92, 95
class sc_pri m_channel 17, 123
creati ng dynami c sensitivi ty 43
non_blocking interface
vs bl ocking 548
non-abstract cl ass, gl ossary 575
non-blocki ng transport 430
non-blocki ng transport i nterf ace 546
non-ignorable extension 575
nor_reduce, reduction operator 197
notes, usage 11
noti ficati on
del ta noti ficati on 100
glossary 575
immedi ate 100
ti med notif ication 100
noti fied
events 16
glossary 575
ti med notif ication 18
noti fy 543
notif y, member function
class sc_event 16, 17, 100, 122
class sc_event_queue 187
delta notif i cati on phase 18
num_attributes, member f unction
class sc_object 129
num_avail abl e, member f unction
class sc_f if o 177
class sc_f ifo_i n 179
class sc_fi fo_i n_i f 172
num_free, member functi on
class sc_f if o 177
class sc_f ifo_out 180
class sc_fi fo_out_if 173
numeric type
def ini ti on 190
glossary 575
O
o_mode, member f uncti on
class sc_f xtype_params 379
li mi ted-precision fi xed-poi nt cl asses 301
object
class sc_object 124
glossary 575
object hierarchy
class sc_object 124
def ini ti on 6
glossary 575
hierarchi cal i nstance name 126
occurrence
class sc_event 97
class sc_report_handler 391
events 16
glossary 575
warni ng 30
operations, addition
li mi ted-precision fi xed-poi nt cl asses 298, 299
variable-preci si on f ixed-point classes 298, 299
operati ons, arithmetic
class sc_i nt 215
class sc_i nt_base 206
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


601
Copyright 2012 IEEE. All rights reserved.
class sc_signed 231
class sc_uint 218
class sc_uint_base 211
class sc_unsi gned 237
f ixed-poi nt classes 297
operations, bi twi se
class sc_bitref_r 280
class sc_bv_base 266
class sc_concref 291
class sc_concref _r 291
class sc_int 215
class sc_i nt_base 206
class sc_logi c 261
class sc_lv_base 272
class sc_signed 232
class sc_subref 285
class sc_subref _r 284
class sc_uint 218
class sc_uint_base 211
class sc_unsi gned 239
f ixed-poi nt classes 297
operations, compari son
class sc_bitref_r 280
class sc_bv_base 267
class sc_concref _r 292
class sc_i nt_base 206
class sc_logi c 261
class sc_lv_base 273
class sc_signed 233
class sc_subref _r 285
class sc_uint_base 211
class sc_unsi gned 240
operator 501
operator bool
bit-select cl asses 221
class sc_fxnum_bitref 369
class sc_fxnum_fast_bitref 369
operator doubl e
class sc_fxnum 332, 336
class sc_fxval_f ast 345
operator I F&
class sc_export 116
operator i nt_type
class sc_i nt_base 206
class sc_i nt_subref _r 226
operator sc_bv_base
class sc_f xnum_f ast_subref 375
class sc_fxnum_subref 375
operator sc_l ogi c
bit-select cl asses 279
operator sc_unsi gned
class sc_signed 255
class sc_si gned_subref _r 252
class sc_unsi gned_subref_r 252
operator uint_type
class sc_uint_base 210
class sc_uint_subref_r 226
operator uint64
bit-select cl asses 248
class sc_unsi gned 255
operator
bit-select cl asses 221, 248
operator!
bit-select cl asses 221, 248
operator! =
class sc_f xcast_switch 382
class sc_f xtype_params 380
class sc_length_param 376
class sc_process_handle 70
operator
concatenation overvi ew 196
integers 255
logi c and vector types 289
templ ate 292
operator() 460, 525, 535, 559
class sc_export 115
class sc_inout 157
class sc_module_name 59
class sc_module, port binding 53
class sc_port 108
part-sel ect cl asses 195
sc_spawn, functi on 64
operator[ ] 461, 534
bit-select cl asses 194
class sc_port 110
operator<
class sc_process_handle 70, 586
operator<< 143
class ostream 143, 175
class sc_sensitive 60
SystemC data types 198
operator=
class sc_buff er 148
class sc_f if o 176
class sc_f xcast_switch 382
class sc_f xtype_params 380
class sc_inout 157
class sc_length_param 376
class sc_process_handle 70
class sc_signal 142
class sc_signal _resol ved 162, 163
operator==
class sc_f xcast_switch 382
class sc_f xtype_params 380
class sc_length_param 376
class sc_process_handle 70
operator-> 461
class sc_export 116
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


602
Copyright 2012 IEEE. All rights reserved.
class sc_port 109
operator>>
SystemC data types 198
option attri bute 476
or_reduce, reducti on operator 197
overfl ow modes 304
overfl ow_f lag
f ixed-poi nt classes 302
overlapping addresses 516
overload, gl ossary 575
overri de, glossary 575
P
parameter, glossary 575
parent
def ini ti on 6
glossary 575
part-sel ect cl asses
def ini ti on 195
fi xed-poi nt types 299
glossary 575
li mi ted-precision integers 222
vectors 280
part-word access 489
passthrough_target_socket 523
passthrough_target_socket_tagged 530
passthrough_target_socket.h 525
payl oad event queue 541
peek 546
pendi ng
cancel, functi on 101
class sc_event_queue 186
glossary 576
update, functi on 18
PEQ 541
peq_wi th_cb_and_phase 542
peq_wi th_get 542
period, member functi on
class sc_clock 151
phase
argument to nb_transport 432
base protocol 503
ignorable 508
message sequence chart 434
PEQ 541
templ ate argument 431
tl m_phase 500
transitions 505
pipeli ni ng 431, 434, 510
pool
memory management 470, 474, 496, 502
port 104
binding 14, 158
class sc_port 111
def ini ti on 5
glossary 576
named binding 53
port bi ndi ng 54
posi ti onal binding 53
port pol icy 15, 106
portless channel access
descri ption 104
glossary 576
posedge_event, member f uncti on
class sc_signal 146
class sc_signal _in_if 137
posedge_f irst, member f unction
class sc_clock 150, 151
posedge, member f uncti on
class sc_signal 146
class sc_signal _in_if 137
posi ti onal binding 53
post, member function
class sc_semaphore 186
pri mitive channel
class sc_buff er 147
class sc_clock 149
class sc_pri m_channel 119
class sc_signal 139, 144
def ini ti on 6
glossary 576
pri nt, member functi on
bit-select cl asses 221, 248, 253, 280
class sc_bv_base 267
class sc_concatref 256
class sc_concref 292
class sc_f if o 177
class sc_f xcast_switch 382
class sc_i nt_base 207
class sc_length_param 376
class sc_l ogi c 261
class sc_l v_base 273
class sc_object 127
class sc_signal 143
class sc_signed 233
class sc_time 103
class sc_unsi gned 240
part-sel ect cl asses 198, 226, 286
proc_ki nd, member f unction
class sc_process_handle 71
process
associ ating 42
clocked thread 43
def ini ti on 6
dynami c sensitivi ty 50
glossary 576
instance 67, 124
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


603
Copyright 2012 IEEE. All rights reserved.
method 43
resume 78
resumed 43
sensiti vity 16
stati c sensitivi ty 48, 60
suspend 78
synchronization 97
triggered 43
process control 73
interaction between member functi ons 86
process handle
class sc_process_handle 67
def ini ti on 6
glossary 576
protocol traits class 455, 456, 467, 498, 502
proxy cl ass
bit-sel ects 194
class sc_generic_base 199, 256
concatenations 196
def ini ti on 191
glossary 576
part-sel ects 195
put 546, 552
Q
q_mode, member functi on
class sc_f xtype_params 379
li mi ted-precision fi xed-poi nt classes 301
quantization modes, def inition 316
quantization_fl ag, member f uncti on
f ixed-poi nt classes 302
quantum 418
global quantum 453
message sequence chart 429
quantum keeper 453, 537
R
range, member f unction
numeri c types and vectors 195
read, member function
class sc_f if o 175
class sc_f if o_i n 179
class sc_f if o_i n_i f 172
class sc_in 153
class sc_inout 157
class sc_signal 141
class sc_si gnal _in_if 135
recipi ent 546
of a transaction 439
of an ignorabl e phase 508
reduction operators 197
re-entrancy
b_transport 514
ref erence count 441, 470, 471, 472, 496, 516
register_port, member functi on
class sc_f if o 175
class sc_interface 118
class sc_signal 141
class sc_signal _resol ved 163
rel ease 471, 472, 496, 505, 519, 520
rel ease_extensi on 496, 497
remove_al l_attributes, member function
class sc_object 129
remove_attribute, member function
class sc_object 129
request exclusi on rule 510
request_update, member f unction
class sc_pri m_channel 17, 121
schedul ing al gorithm 16
reset
generi c payload 471, 472, 496
quantum keeper 539
reset_event, member f uncti on
class sc_process_handl e 81, 83, 585
reset_si gnal _i s, member f unction
class sc_module 24, 46, 585
class sc_spawn_options 24, 63, 585
reset, member function
class sc_process_handle 81, 585
resize_extensions 497, 544
resolved signal
class sc_i n_resolved 164
class sc_in_rv 168
class sc_i nout_resolved 165
class sc_inout_rv 169
class sc_out_resol ved 166
class sc_signal _resol ved 161
class sc_signal _rv 168
def ini ti on 161
glossary 577
response exclusi on rule 511
response status attribute 474, 483
DMI 445
extensi ons 484
modif icati on at target 476
update_ori ginal _from 473
resume
class sc_event 97
dont_initiali ze, f uncti on 48
eval uation phase 17
glossary 577
lock, function 183
noti fy, function 100
sc_start, function 22
schedul er 15
thread process 43
wait, function 52
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


604
Copyright 2012 IEEE. All rights reserved.
resume process 78
resume, member f unction
class sc_process_handle 78, 585
return path 421
message sequence chart 435
reverse, member f unction
class sc_bv_base 267
class sc_concref 290
class sc_lv_base 271
part-sel ect cl asses 286
reversed, member f uncti on
part-sel ect cl asses 286
rounding modes 317
routing
address attribute 476
base protocol 515
rrotate, member functi on
class sc_bv_base 267
class sc_concref 290
class sc_lv_base 271
part-sel ect cl asses 285
rvalue, glossary 577
S
SC_ABORT, val ue of type sc_actions 391, 398
sc_abs, functi on 411
sc_actions, typedef 393
SC_ALL_BOUND, val ue of type sc_port_pol icy
104
sc_argc, function 21
sc_argv, function 21
sc_assemble_vector, f unction 400, 587
sc_assert, macro 394
sc_attr_base, cl ass 131
sc_attr_cltn, class 133
sc_attri bute, class 132
SC_BEFORE_END_OF_ELABORATION, value
of type sc_status 28
sc_behavior, typedef 39, 56
sc_bigi nt, cl ass template 190, 240
sc_biguint, cl ass template 190, 242
SC_BIN_SM, value of type sc_numrep 383
SC_BIN_US, val ue of type sc_numrep 383
SC_BIN, value of type sc_numrep 383
SC_BIND_PROXY_NIL, const 37
sc_bind_proxy, class 37
sc_bind, macro 65
sc_bit, type (deprecated) 584
sc_bitref _r, cl ass template 277
sc_bitref, class templ ate 277
sc_buff er, cl ass 147
derived from sc_si gnal 144
sc_bv_base, class 190, 262
sc_bv, cl ass template 190, 273
SC_CACHE_REPORT, val ue of type sc_actions
388, 391, 398
sc_channel, typedef 39, 56
sc_clock, class 149
sc_close_vcd_trace_f il e, f uncti on 386
sc_concatref , cl ass 253
sc_concref _r, class templ ate 286
sc_concref , cl ass template 286
sc_context_begin, cl ass 377, 380, 382, 383
sc_copyright 412
sc_copyright_string, f unction 411
sc_copyright, functi on 412
SC_COPYRI GHT, macro 411
sc_core, namespace 10, 20
sc_create_vcd_trace_f i le, f unction 386
sc_cref, macro 65
SC_CSD, value of type sc_numrep 200, 383
SC_CTHREAD_PROC_, sc_curr_proc_kind const
68, 71
sc_cthread_process 44
SC_CTHREAD, macro 14, 39, 41
SC_CTOR, macro 39, 40, 58
sc_curr_proc_kind, enumerati on 68
sc_cycl e, f uncti on (deprecated) 583
SC_DEBUG, val ue of type sc_verbosi ty 389
SC_DEC, val ue of type sc_numrep 383
SC_DEFAULT_ERROR_ACTIONS, macro 393
SC_DEFAULT_FATAL_ACTIONS, macro 393
SC_DEFAULT_INFO_ACTI ONS, macro 393
SC_DEFAULT_STACK_SI ZE, const (deprecated)
583
SC_DEFAULT_WARNING_ACTI ONS, macro
393
sc_delta_count, f unction 31, 585
sc_descendant_inclusion_info, enumerati on 68, 585
SC_DISPLAY, value of type sc_acti ons 391, 398
SC_DO_NOTHI NG, val ue of type sc_actions 391,
398
sc_dt, namespace 10, 189
SC_E, value of type sc_fmt 303
sc_elab_and_si m, function 20
SC_ELABORATI ONS, value of type sc_status 28
SC_END_OF_ELABORATI ON, val ue of type
sc_status 28
sc_end_of_simul ation_invoked, function 24
SC_END_OF_SI MULATION, value of type
sc_status 28
SC_ERROR, sc_severi ty constant 388, 390
sc_event_and_expr, class 95
sc_event_and_list, class 92, 586
sc_event_f inder_t, class templ ate 90
sc_event_f inder, class 61, 90, 157
sc_event_or_expr, class 95
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


605
Copyright 2012 IEEE. All rights reserved.
sc_event_or_l ist, class 92, 586
sc_event_queue_if , cl ass 186
sc_event_queue, class 186
sc_event, cl ass 16, 97
sc_excepti on, typedef 399
SC_EXIT_ON_STARVATI ON, val ue of type
sc_starvati on_policy 20, 22
sc_export_base, cl ass 113, 114
sc_export, class 113
SC_F, value of type sc_fmt 303
SC_FATAL, sc_severity constant 388, 390
sc_f if o_blocking_in_if cl ass 171
sc_f if o_i n_i f, class 171
sc_f if o_i n, class 178
sc_f if o_nonbl ocki ng_in_if , cl ass 171
sc_f if o_out_i f, class 172
sc_f if o_out, class 179
sc_f if o, class 173
sc_f ind_event, function 100, 586
sc_f ind_object, f uncti on 128
sc_f ix_fast, cl ass 190, 296, 352
sc_f ix, cl ass 190, 295, 346
sc_f ixed_f ast, class templ ate 190, 296, 362
sc_f ixed, class templ ate 190, 358
sc_f mt, enumeration 303
SC_FORK, macro 66
SC_FS, value of type sc_time_unit 101
SC_FULL, val ue of type sc_verbosity 389
sc_f xcast_context, class 382
sc_f xcast_swi tch, cl ass 381
sc_f xnum_bitref , class 367
sc_f xnum_f ast_bitref , cl ass 367
sc_f xnum_f ast_subref , cl ass 369
sc_f xnum_f ast, class 190, 332
sc_f xnum_subref , class 369
sc_f xnum, class 190, 295, 327
sc_f xtype_context, class 380
sc_f xtype_params, class 378
sc_f xval_f ast, class 190, 296, 341
sc_f xval, class 190, 295, 337
sc_gen_unique_name, function 39, 56
sc_gen_unique_name, sockets 460
sc_generic_base, class 256
sc_get_curr_process_handle, functi on (deprecated)
583
sc_get_current_process_handle, function 88
sc_get_def aul t_ti me_uni t, functi on (deprecated)
583
sc_get_status, f unction 32, 585
sc_get_stop_mode, function 29
sc_get_ti me_resolution, f unction 103
sc_get_top_level _events, f uncti on 100, 586
sc_get_top_level _obj ects, function 128
SC_HAS_PROCESS, macro 39, 41
SC_HEX_SM, val ue of type sc_numrep 383
SC_HEX_US, value of type sc_numrep 383
SC_HEX, val ue of type sc_numrep 383
sc_hierarchi cal _name_exists, functi on 130, 586
SC_HIGH, value of type sc_verbosity 388
sc_in_clk, typedef 151
sc_i n_resolved, cl ass 164
sc_i n_rv, class 168
sc_i n, class 152
speciali zed port 144
sc_i n<bool>, class 153
sc_i n<sc_dt::sc_logic>, cl ass 153
SC_INCLUDE_DESCENDANTS
process control 77
SC_INCLUDE_DESCENDANTS ,
sc_descendant_inclusion_info constant 68
SC_INFO, sc_severi ty constant 388, 390
SC_INFO, standard error response 485
sc_i ni ti al ize, f unction (deprecated) 583
sc_i nout_clk, typedef (deprecated) 583
sc_inout_resolved, class 165
sc_i nout_rv, cl ass 169
sc_inout, class 156
speciali zed port 144
sc_int_base, class 190, 203
sc_int_bi tref_r, class 217
sc_i nt_bi tref, cl ass 218
sc_int_subref _r, cl ass 222
sc_i nt_subref , cl ass 222
sc_i nt, cl ass template 190, 213
sc_i nterf ace, cl ass 117
sc_interrupt_here, functi on 398
SC_INTERRUPT, value of type sc_acti ons 391,
398
sc_i s_prerel ease, f uncti on 411
SC_IS_PRERELEASE, macro 411
sc_is_running, function 31
sc_is_unwinding, f unction 89, 585
SC_JOI N, macro 66
SC_LATER, constant of type sc_context_begi n
193, 377, 380, 383
sc_length_context, class 377
sc_length_param, cl ass 375
SC_LOG, val ue of type sc_actions 391, 398, 399
SC_LOGIC_0, const 261
SC_LOGIC_1, const 261
sc_l ogi c_value_t, enumerati on 257
SC_LOGIC_X, const 261
SC_LOGIC_Z, const 261
sc_logi c, class 190, 257
SC_LOW, value of type sc_verbosi ty 388
sc_l v_base, cl ass 190, 267
sc_lv, class templ ate 190, 275
sc_main, functi on 21
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


606
Copyright 2012 IEEE. All rights reserved.
cal li ng sc_start 22
SC_MAX_NUM_DELTA_CYCLES, const (depre-
cated) 583
SC_MAX_SEVERI TY, sc_severity constant 388
sc_max_ti me, f uncti on 103, 586
sc_max, function 411
SC_MEDI UM, value of type sc_verbosity 388
SC_METHOD_PROC_, sc_curr_proc_kind con-
stant 68, 71
sc_method_process 43
SC_METHOD, macro 14, 39, 41
sc_mi n, f unction 411
sc_module_name, class
def ini ti on 57
module instantiati on 13
usage i n sc_modul e constructor 39
sc_module, cl ass
def ini ti on 37
member sensitive 60
use of sc_module_name 58
SC_MODULE, macro 39, 40
SC_MS, sc_ti me_uni t constant 101
sc_mutex_if , cl ass 182
sc_mutex, cl ass 182, 587
SC_NO_DESCENDANTS
process 77
SC_NO_DESCENDANTS ,
sc_descendant_inclusion_i nfo constant 68
SC_NO_PROC_, sc_curr_proc_ki nd constant 68,
71
SC_NOBASE, val ue of type sc_numrep 383
SC_NONE, value of type sc_verbosi ty 388
SC_NOW, constant of type sc_context_begi n 193,
377, 380, 383
SC_NS, sc_ti me_unit constant 101
sc_numrep, enumeration 199, 383
sc_o_mode, enumeration 301
sc_object, cl ass
def ini ti on 124
usage of sc_modul e_name 58
SC_OCT_SM, val ue of type sc_numrep 383
SC_OCT_US, value of type sc_numrep 383
SC_OCT, val ue of type sc_numrep 383
SC_OFF, constant of type sc_swi tch 300, 382
SC_ON, constant of type sc_switch 300, 382
SC_ONE_OR_MORE_BOUND, value of type
sc_port_poli cy 104
sc_out_clk, typedef (deprecated) 583
sc_out_resolved, class 166
sc_out_rv, class 170
sc_out, class 160
speciali zed port 144
sc_pause, f unction 28, 585
SC_PAUSED, val ue of type sc_status 28
sc_pendi ng_activity_at_current_ti me, f uncti on 32,
586
sc_pendi ng_activity_at_f uture_ti me, function 32,
586
sc_pendi ng_activity, function 32, 586
sc_phash, cl ass (deprecated) 584
sc_pli st, cl ass (deprecated) 584
sc_port 460
sc_port_base, class 104
sc_port_pol icy, enumerati on 104
sc_port, cl ass
def ini ti on 105
posi ti onal port bi ndi ng 54
sc_ppq, class (deprecated) 584
sc_pri m_channel , cl ass 16
def ini ti on 119
module hierarchy 58
sc_process_b, type (deprecated) 583
sc_process_handle 42
sc_process_handle, cl ass 67
SC_PS, sc_time_unit constant 101
sc_pvector, cl ass (deprecated) 584
sc_q_mode, enumerati on 301
sc_ref , macro 65
sc_rel ease, f unction 412
SC_REPORT_ERROR, macro 394
SC_REPORT_FATAL, macro 394
sc_report_handler_proc, typedef 397
sc_report_handler, cl ass 391
SC_REPORT_INFO_VERB, macro 394, 587
SC_REPORT_I NFO, macro 394
SC_REPORT_WARNI NG, macro 394
sc_report, cl ass 388
SC_RND_CONV, quantization mode 324
SC_RND_INF, quantizati on mode 323
SC_RND_MI N_INF, quantization mode 322
SC_RND_ZERO, quanti zati on mode 321
SC_RND, quanti zation mode 319
SC_RUN_TO_TIME, value of type
sc_starvati on_poli cy 20, 22
SC_RUNNI NG, val ue of type sc_status 28
SC_SAT_SYM, overf low mode 309
SC_SAT_ZERO, overf low mode 309
SC_SAT, overf low mode 308
SC_SEC, sc_time_unit constant 101
sc_semaphore_if , cl ass 184
sc_semaphore, class 185, 587
sc_sensitive_neg, class (deprecated) 583
sc_sensitive_pos, cl ass (deprecated) 583
sc_sensitive, cl ass
data member of sc_module 48
module instantiati on 13
sc_sensitive, cl ass defi nition 60
sc_set_def aul t_ti me_uni t, f uncti on (deprecated) 583
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


607
Copyright 2012 IEEE. All rights reserved.
sc_set_stop_mode, f unction 29
sc_set_ti me_resolution
quantum keeper 540
setti ng the ti me resol uti on 15
sc_set_time_resoluti on, f uncti on 15, 103
sc_set_vcd_ti me_uni t, member f uncti on (deprecat-
ed) 584
sc_severi ty, enumeration 388, 389
sc_signal _in_if , cl ass 135
sc_signal _in_if <bool >, cl ass 136
sc_signal _in_if <sc_logic>, cl ass 136
sc_signal _inout_if , cl ass 137
sc_signal _out_if , typedef (deprecated) 583
sc_signal _resol ved, class 161
mul tipl e writers 144
sc_signal _rv, cl ass 167
sc_signal_wri te_if , cl ass 137
sc_signal , cl ass 139
sc_signal<bool >, cl ass 144
sc_signal <sc_logi c>, class 144
sc_signed_bitref_r, cl ass 244
sc_signed_bitref , class 244
sc_signed_subref _r, class 248
sc_signed_subref , class 248
sc_signed, class 190, 227
sc_simcontext, cl ass (deprecated) 583
sc_simul ation_ti me, function (deprecated) 583
sc_spawn_options, cl ass 61
sc_spawn, functi on 61, 64
sc_start_of _si mulati on_i nvoked, f uncti on 24
SC_START_OF_SI MULATI ON, val ue of type
sc_status 28
sc_start, function 21, 585
sc_start(double), functi on (deprecated) 583
sc_starvati on_poli cy, enumeration 20, 585
sc_status, enumerati on 28
sc_status, f unction 585
SC_STOP_FI NI SH_DELTA 30
SC_STOP_FI NI SH_DELTA, value of type
sc_stop_mode 27, 29, 30
sc_stop_here, functi on 398
SC_STOP_IMMEDIATE, value of type
sc_stop_mode 27, 29, 30
sc_stop_mode, enumeration 27
sc_stop, f unction 29
impact on cl ock 150
SC_STOP, value of type sc_acti ons 391, 398
SC_STOPPED, value of type sc_status 28
sc_string, cl ass (deprecated) 584
sc_subref_r, class templ ate 280
sc_subref, class template 280
sc_switch, class 381
SC_THREAD_PROC_, sc_curr_proc_ki nd con-
stant 68, 71
sc_thread_process 44
SC_THREAD, macro 14, 39, 41
SC_THROW, value of type sc_acti ons 389, 391,
398
sc_time
argument to nb_transport 438
sc_time_stamp
b_transport 427
base protocol 514
global quantum 453, 454
PEQ 541
quantum keeper 540
schedul er 417
ti mi ng annotation 438
sc_ti me_stamp, f unction 30
sc_ti me_to_pending_activity, f uncti on 32, 586
sc_time_uni t, enumerati on 101
sc_ti me, cl ass 16, 101
sc_trace_del ta_cycl es, function (deprecated) 584
sc_trace_f ile, class 385
sc_trace, functi on 153, 157, 386, 388
SC_TRN_ZERO, quanti zati on mode 326
SC_TRN, quanti zati on mode 325
sc_ufi x_f ast, cl ass 190, 296
sc_ufi x, cl ass 190, 295, 349
sc_ufi xed_fast, class templ ate 190, 365
sc_ufi xed, class template 190, 360
sc_uint_base, class 190, 208
sc_uint_bi tref _r, class 218
sc_uint_bi tref , cl ass 218
sc_uint_subref_r, cl ass 222
sc_uint_subref, class 222
sc_uint, cl ass templ ate 190, 215
sc_unnamed, namespace 10, 587
sc_unsi gned_bitref_r, class 244
sc_unsi gned_bi tref, class 245
sc_unsi gned_subref _r, cl ass 248
sc_unsi gned_subref , cl ass 248
sc_unsi gned, cl ass 190, 234
SC_UNSPECIFI ED, val ue of type sc_actions 391,
398
sc_unwind_exception cl ass 82
sc_unwind_exception, function 585
SC_US, sc_time_unit constant 101
sc_value_base, class 201
sc_vector_assembly, cl ass 400, 586
sc_vector_base, cl ass 400, 586
sc_vector, class 400, 586
sc_verbosi ty, enumerati on 388, 587
sc_version_maj or, functi on 411
SC_VERSION_MAJOR, macro 411, 587
sc_version_minor, functi on 411
SC_VERSION_MINOR, macro 411, 587
sc_version_originator, f unction 411
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


608
Copyright 2012 IEEE. All rights reserved.
SC_VERSION_ORIGI NATOR, macro 411
sc_version_patch, function 411
SC_VERSION_PATCH, macro 411, 587
sc_version_prerelease, function 411
SC_VERSION_PRERELEASE, macro 411
sc_version_release_date, f uncti on 411
SC_VERSION_RELEASE_DATE, macro 411
sc_version_stri ng, functi on 411
sc_version, function 412
SC_VERSION, macro 411
SC_WARNING
standard error response 485
SC_WARNING, sc_severity constant 388, 390
SC_WRAP_SM, overfl ow mode 312
SC_WRAP, overfl ow mode 310
sc_write_comment, function 386
sc_writer_pol icy, enumerati on 137, 587
SC_ZERO_OR_MORE_BOUND, value of type
sc_port_poli cy 104
SC_ZERO_TIME, const 103
scan, member function
bit-select cl asses 221, 248, 253, 280
class sc_bv_base 267
class sc_concatref 256
class sc_concref 292
class sc_i nt_base 207
class sc_logi c 261
class sc_lv_base 273
class sc_signed 233
class sc_uint_base 212
class sc_unsi gned 239
part-sel ect cl asses 226, 286
SystemC data types 198
schedul ed
descri ption 563
glossary 577
multipl e event notif ication 101
schedul er 417
behavior 15
glossary 577
sender 546
sensiti ve, data member
class sc_module 48
sensitivity
dynami c 52
glossary 577
method process i nstance 43, 50
spawned process i nstance 63
thread process i nstance 43
unspawned process instance 48, 60
set
quantum keeper 540
tl m_global _quantum 454
set_address 478
set_and_sync 540
set_auto_extensi on 473, 496
set_byte_enable_length 481
set_byte_enabl e_ptr 480
set_command 477
set_data_length 480
set_data_ptr 479
set_dmi_al lowed 482
set_dmi_ptr 446
set_end_address 447
set_extensi on 472, 473, 495, 544
set_gl obal _quantum 540
set_gp_option, member functi on
class tl m_generi c payload 476
class tl m_generi c_payload 588
set_granted_access 446
set_mm 471
set_read 478
set_read_l atency 448
set_response_status 483
set_sensi ti vi ty, member f uncti on
class sc_spawn_options 24, 63
set_stack_si ze, member f uncti on
class sc_module 24, 49
class sc_spawn_options 63
set_start_address 447
set_streaming_width 482
set_time_unit, member function
class sc_trace_fi le 386
set_verbosity_l evel, member f uncti on
class sc_report_handler 587
sc_report_handler 396
set_wri te 478
set_wri te_latency 448
shal l, usage 5
shoul d, usage 5
sign extension 192
signal
def ini ti on 6
glossary 577
reading and writing 140
resolved 161, 162
val ue of sc_si gnal 139
signature, gl ossary 577
simpl e 526, 528
simpl e socket 523
b/nb conversion 526
binding 522
nb_transport 432
tagged 529
simpl e_ini ti ator_socket 523
simpl e_ini ti ator_socket_tagged 529
simpl e_ini ti ator_socket.h 525
simpl e_target_socket 524
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


609
Copyright 2012 IEEE. All rights reserved.
simpl e_target_socket_tagged 529
simpl e_target_socket.h 525
simul ation
behavior 15
cal lbacks 23
end_of_simul ation, function 27
glossary 578
sc_elab_and_si m, function 20
semantics 12
start_of _si mulati on, f uncti on 26
simul ation ti me 30
single-bi t logic types, defi ni ti on 189
size, member f unction
class multi_passthrough_target_socket 535
class sc_port 109
class sc_vector_base 405
class tl m_base_target_socket 461
class tl m_fi fo_debug_if 552
socket
binding 522
convenience 419, 456
ini ti ator 422, 456
multi-socket 461
simpl e 432, 523
standard 414
tagged 529, 531
target 422
spawn_method, member f unction
class sc_spawn_options 63
spawned process
class sc_spawn_options 61
def ini ti on 6
glossary 578
parent 124
SC_FORK, macro 66
SC_JOI N, macro 66
sc_spawn, functi on 61
sensiti vity 16
speciali zed port
class sc_f if o_i n 178
class sc_fi fo_out 179
class sc_in 152
class sc_in_resolved 164
class sc_in_rv 168
class sc_in<bool> 153
class sc_in<sc_dt::sc_logic> 153
class sc_inout 156
class sc_inout_resolved 165
class sc_inout_rv 169
class sc_inout<bool> 158
class sc_inout<sc_dt::sc_logic> 158
get_interface, f uncti on 112
glossary 578
standard error response 466, 478, 479, 480, 481,
482, 483, 484
standard sockets 414
start_of _si mulati on, member f uncti on 26
class sc_export 117
class sc_module 55
class sc_port 112
class sc_pri m_channel 123
start_time, member f uncti on
class sc_clock 151
statement, glossary 578
stati c process
clocked thread process 44
def ini ti on 6
descri ption 563
dynami c, f unction 72
glossary 578
stati c sensitivi ty
def ini ti on 16
glossary 578
stati c, spawned process
sc_spawn, functi on 64
streami ng wi dth attribute 482
string l iteral 199
string name
basename, functi on 126
case-sensitivi ty 56
constructor sc_export 114
constructor sc_module 40
constructor sc_object 126
constructor sc_port 107
constructor sc_pri m_channel 121
glossary 578
module instance 39
sc_gen_unique_name, f unction 56
sc_module_name, functi on 57
sc_spawn, functi on 65
sub-obj ect, gl ossary 578
suspend process 78
suspend, glossary 578
suspend, member f uncti on
class sc_process_handle 78, 585
swap, member f uncti on
class sc_process_handle 71, 586
sync_reset_of f, member f uncti on
class sc_process_handle 73, 585
sync_reset_on, member functi on
class sc_process_handle 83, 585
synchronizati on-on-demand 418, 540
synchronous message passing 546
synchronous reset state
glossary 579
SystemC cl ass library 35
systemc.h 35
systemc.h, C++ header fi le 35
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


610
Copyright 2012 IEEE. All rights reserved.
T
tagged sockets 531
target socket 422
terminated
glossary 579
method process 43
process instance 44
sc_process_handle 67
terminated_event, member functi on
class sc_process_handle 73
terminated, member function
class sc_process_handle 72, 586
terminology 5
thread process
arguments f or macros 42
class sc_process_handle 67
glossary 579
ini ti al ization phase 17
interf ace methods 564
reset_si gnal _i s, f uncti on 44
set_stack_si ze, functi on 49
terminated, function 72
wait, function 43, 52
throw_it, member f unction
class sc_process_handle 84, 585
ti me resol ution 15, 102
ti me warp 417
ti med notif ication
class sc_event 100
class sc_event_queue 187
def ini ti on 17
glossary 579
schedul ing al gorithm 16
ti med notif ication phase
def ini ti on 18
glossary 579
ti me-out
def ini ti on 17
elapsed time i nterval 16
glossary 579
ti med notif ication phase 18
TLM_ACCEPTED 433
message sequence chart 434
TLM_ADDRESS_ERROR_RESPONSE 479
tl m_anal ysis_fi fo 558
tl m_anal ysis_if 558
tl m_anal ysis_port 558
tl m_base_initiator_socket_b 460
tl m_base_initiator_socket, 460
tl m_base_protocol_types 455, 456, 462
tl m_base_target_socket 460
tl m_base_target_socket_b 460
TLM_BI G_ENDIAN 491
tl m_blocki ng_get_if 547
tl m_blocking_get_peek_if 548
tl m_blocking_peek_if 547
tl m_blocking_put_i f 547
tl m_blocking_transport_if 427
TLM_BURST_ERROR_RESPONSE 469, 480
tl m_bw_di rect_mem_i f 443
tl m_bw_nonblocki ng_transport_if 430
tl m_bw_transport_i f 455
TLM_BYTE_DI SABLED 469
TLM_BYTE_ENABLE_ERROR_RESPONSE 481
TLM_BYTE_ENABLED 469
tl m_command 468
TLM_COMMAND_ERROR_RESPONSE 469
TLM_COMPLETED 433
base protocol 503
data transfer time 510
message sequence chart 435
response status attri bute 484
TLM_COPYRI GHT 424
tl m_copyright_stri ng, f uncti on 424
tl m_copyright, functi on 424
TLM_DECLARE_EXTENDED_PHASE 500, 588
tl m_dmi 442, 445
tl m_endi anness 490
tl m_extension 495
tl m_extension_base 495
tl m_fi fo 546, 551, 552
tl m_fi fo_debug_if 551
tl m_fi fo_get_if 551
tl m_fi fo_put_if 551
TLM_FULL_PAYLOAD
transport_dbg 452
val ue of type tlm_gp_option 468
TLM_FULL_PAYLOAD_ACCEPTED
transport_dbg 452
val ue of type tlm_gp_option 468
tl m_fw_di rect_mem_if 445, 455
tl m_fw_nonblocki ng_transport_if 430
tl m_fw_transport_if 455
TLM_GENERI C_ERROR_RESPONSE 469
tl m_generi c_payload. See generi c payload
tl m_get_if 548
tl m_get_peek_if 548
tl m_global _quantum 418, 453
tl m_gp_opti on, enumeration 468, 588
TLM_I GNORE_COMMAND 468
DMI 445
response status 483
transport_dbg 451, 588
TLM_I NCOMPLETE_RESPONSE 469
response status 483
tl m_ini ti ator_socket 461
TLM_I S_PRERELEASE 424, 588
tl m_is_prerelease, functi on 424
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


611
Copyright 2012 IEEE. All rights reserved.
TLM_LI TTLE_ENDIAN 491
TLM_MIN_PAYLOAD
transport_dbg 452
val ue of type tlm_gp_opti on 468
tl m_mm_i nterf ace 468, 471
tl m_nonbl ocking_get_i f 547
tl m_nonbl ocking_get_peek_i f 548
tl m_nonbl ocking_peek_i f 547
tl m_nonbl ocking_put_i f 547
TLM_OK_RESPONSE 468
base protocol 517
response status 483
tl m_peek_if 548
tl m_phase 431, 455, 466, 467, 500
tl m_phase_enum 500, 523, 526
tl m_put_if 547
tl m_quantumkeeper 418, 433, 453, 537
TLM_READ_COMMAND 468
generi c payload 473
transport_dbg 451
tl m_rel ease 425
tl m_rel ease, f uncti on 424
tl m_response_status 468
tl m_sync_enum 433, 434
tl m_tag 546
tl m_target_socket 461
tl m_transport_dbg_if 451
tl m_transport_i f 548
TLM_UNKNOWN_ENDI AN 491
TLM_UPDATED 433
base protocol 503
message sequence chart 435
tl m_uti ls 423
tl m_uti ls di rectory 424
tl m_uti ls, namespace 10
TLM_VERSI ON 424
tl m_version 425
TLM_VERSI ON_MAJOR 424
tl m_version_maj or, functi on 424
TLM_VERSI ON_MI NOR 424
tl m_version_minor, functi on 424
TLM_VERSI ON_ORIGINATOR 424
tl m_version_originator, f unction 424
TLM_VERSI ON_PATCH 424
tl m_version_patch, function 424
TLM_VERSI ON_PRERELEASE 424
tl m_version_prerelease, function 424
TLM_VERSI ON_RELEASE_DATE 424
tl m_version_release_date, functi on 424
tl m_version_string, function 424
tl m_version, f unction 424
TLM_WRITE_COMMAND 468
DMI 445
transport_dbg 451
tl m_write_if 558
tl m, namespace 10
tl m.h 424, 587
TLM-1
codi ng styl es 416
mi grati on path from 442
TLM-2.0 413
TLM-2.0-compl iant-impl ementation 588
to_bin, member f uncti on
class sc_f xnum 332, 337
class sc_f xval 341
class sc_f xval_f ast 346
to_bool , member function
bit-select cl asses 279
class sc_l ogi c 260
to_char, member function
bit-select cl asses 279
class sc_l ogi c 260
to_dec, member f uncti on
class sc_f xnum 332, 337
class sc_f xval 341
class sc_f xval_f ast 346
to_doubl e, member f uncti on
class sc_f xnum 332, 336
class sc_f xval 341
class sc_f xval_f ast 345
class sc_time 103
to_f loat, member functi on
class sc_f xnum 332, 336
class sc_f xval 341
class sc_f xval_f ast 345
to_hex, member f uncti on
class sc_f xnum 332, 337
class sc_f xval 341
class sc_f xval_f ast 346
to_hostendian 491
to_int, member function
class sc_f xnum 332, 336
class sc_fxnum_fast_subref 375
class sc_f xnum_subref 375
class sc_f xval 341
class sc_f xval_f ast 345
SystemC data types 198
to_i nt64, member f uncti on
class sc_f xnum 332, 336
class sc_fxnum_fast_subref 375
class sc_f xnum_subref 375
class sc_f xval 341
class sc_f xval_f ast 345
class sc_generic_base 257
SystemC data types 198
to_long, member function
class sc_f xnum 332, 336
class sc_fxnum_fast_subref 375
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


612
Copyright 2012 IEEE. All rights reserved.
class sc_fxnum_subref 375
class sc_f xval 341
class sc_fxval_f ast 345
SystemC data types 198
to_oct, member functi on
class sc_fxnum 332, 337
class sc_f xval 341
class sc_fxval_f ast 346
to_sc_signed, member f uncti on
class sc_generic_base 257
to_sc_unsi gned, member function
class sc_generic_base 257
to_seconds, member functi on
class sc_time 103
to_short, member f uncti on
class sc_fxnum 332, 336
class sc_f xval 341
class sc_fxval_f ast 345
to_string, member function 384
bit concatenati on cl asses 289
class sc_bv_base 265
class sc_f xcast_swi tch 382
class sc_fxnum 332, 336
class sc_f xnum_f ast_subref 375
class sc_fxnum_subref 375
class sc_f xval 341
class sc_fxval_f ast 346
class sc_i nt_base 206
class sc_length_param 376
class sc_lv_base 270
class sc_signed 230
class sc_time 103
class sc_uint_base 211
class sc_unsi gned 236, 255
f ixed-poi nt classes 303
part-sel ect cl asses 226, 253, 283
SystemC numeric types 200
to_uint, member f unction
class sc_fxnum 332, 336
class sc_f xnum_f ast_subref 375
class sc_fxnum_subref 375
class sc_f xval 341
class sc_fxval_f ast 345
SystemC data types 198
to_uint64, member functi on
class sc_fxnum 332, 336
class sc_f xnum_f ast_subref 375
class sc_fxnum_subref 375
class sc_f xval 341
class sc_fxval_f ast 345
class sc_generic_base 256
SystemC data types 198
to_ulong, member f unction
class sc_fxnum 332, 336
class sc_fxnum_fast_subref 375
class sc_f xnum_subref 375
class sc_f xval 341
class sc_f xval_f ast 345
SystemC data types 198
to_ushort, member functi on
class sc_f xnum 332, 336
class sc_f xval 341
class sc_f xval_f ast 345
top-level modul e
def ini ti on 7
glossary 580
top-level obj ect
def ini ti on 124
get_parent_object, f uncti on 128
glossary 580
sc_spawn, functi on 64
trace fi le 385
traits class 455, 456
transaction orderi ng
b_transport 514
base protocol 515
summary 517
ti mi ng annotation 438, 514
transaction-l evel modeli ng 1, 413, 415
transparent component 508
transport 546
transport interface 419, 426
DMI 449
TLM-1 546
TLM-2.0 546
transport_dbg 451, 452, 588
memory management 471
payl oad attributes 474
trigger
class sc_event 97
dont_initiali ze, f uncti on 48
eval uation phase 17
glossary 580
method process 43
next_tri gger, function 17, 50
process sensi ti vi ty 16
schedul er 15
trylock, member f unction
class sc_mutex 183
trywai t, member f unction
class sc_semaphore 186
type of a port
def ini ti on 54
templ ate parameters 105
type_params, member functi on
li mi ted-precision fi xed-poi nt cl asses 302
typedef
const_i terator 133
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


613
Copyright 2012 IEEE. All rights reserved.
elem_type 133
int_type 203
int64 203
iterator 133
sc_actions 393
sc_behavior 39, 56
sc_channel 39, 56
sc_excepti on 399
sc_in_clk 151
sc_i nout_clk (deprecated) 583
sc_out_clk (deprecated) 583
sc_report_handler_proc 397
sc_signal _out_i f (deprecated) 583
uint_type 203
uint64 203
U
uint_type, typedef 203
uint64, typedef 203
unbi nd 559
undef ined
errors 11
glossary 581
UNI NITI ALIZED_PHASE 500, 501
unlock, member f uncti on
class sc_mutex 184
unspawned process
class sc_object 124
class sc_process_handle 67
creating 42
def ini ti on 6
glossary 581
instance 14
sensiti vity 16
stati c sensitivi ty 16, 48
untimed codi ng styl e 416
update phase
def ini ti on 18
glossary 581
update request 16, 24, 121, 142
update_extensions_from 474
update_ori ginal_from 473, 474
update, member f uncti on 18
class sc_buff er 148
class sc_f if o 176
class sc_pri m_channel 17, 122
class sc_signal 142
class sc_si gnal _resol ved 162, 163
use_byte_enabl e_on_read 473
used 552
user, gl ossary 581
user-defi ned conversion, gl ossary 581
V
val id, glossary 581
val id, member f uncti on
class sc_process_handle 69
val ue_changed_event, member function
class sc_in 153
class sc_inout 157
class sc_signal 142
class sc_signal _in_if 135
val ue_changed, member f unction
class sc_in 153
class sc_inout 157
val ue, member f unction
class sc_f xcast_context 383
class sc_f xtype_context 381
class sc_length_context 377
class sc_l ogi c 260
class sc_time 103
f ixed-poi nt classes 302
variable-preci si on f ixed-point type
def ini ti on 189
glossary 582
VCD f il e 385, 386
vector
glossary 582
usage 190
verbosi ty level 396
version information 424
W
wait
b_transport 427
DMI 444
nb_transport 431
temporal decoupl ing 538
tl m_sync_enum 433
transport_dbg 452
wait, member function
class sc_module 17, 43, 52, 92, 95
class sc_pri m_channel 17, 43, 123
class sc_semaphore 186
delta notif i cati on phase 18
warni ng
def ini ti on 11
glossary 582
what, member f uncti on
class sc_unwind_exception 82
wi dth conversi on 482, 490
wi thin
def ini ti on 6
glossary 582
port bi ndi ng 14
wl , member f unction
IEEE Std 1666-2011
IEEE Standard for Standard SystemC

Language Reference Manual


614
Copyright 2012 IEEE. All rights reserved.
class sc_f xtype_params 380
li mi ted-precision fi xed-poi nt classes 302
word, endi anness 487, 491
write 558
write, member f uncti on
class sc_buff er 148
class sc_clock 151
class sc_f if o 176
class sc_fi fo_out 180
class sc_fi fo_out_if 173
class sc_inout 157
class sc_signal 142
class sc_signal _inout_if 138
class sc_si gnal _resol ved 162, 163
class sc_signal _rv 168
class sc_signal _wri te_if 137
WRITER_POLICY 587
X
xnor_reduce, reduction operator 197
xor_reduce, reduction operator 197
Y
yield
DMI 449
loosel y-timed 417
quantum keeper 540
synchronization 418
temporal decoupli ng 538
tl m_sync_enum 433
Z
zero extension 192

You might also like