Aa!Xff  @```p@ p00 Pp`pP0`P H $ d HHUÙ̀̀ff@  d Footnote TableFootnote**/ - :;,.!? g7 !g?LOPH2,1.1H3,1.1.1 H4,1.1.1.1 H5,1.1.1.1.1TOCH2,1.1H3,1.1.1 H4,1.1.1.1 H5,1.1.1.1.1 NumberedList1 NumberedList2CAPIsDirectCMyTypePLIs SystemVerilogVerilogan_unsized_arrayargarravaluebvaluecalleecnameconst d=destination d=dimensionelem endfunction export_declexternfname foo(input getStimulus global_funchinhouti=bit i=startinginoutintlongintmallocmyInitmy_tabmy_value name_of_queueptrs=scalars=sourceshortint shortrealstructsubrangesvsvBitsvBitPackedArrRefsvGetBitArrElemsvGetLogicArrElemsvHandlesvLogicsvLogicPackedArrRefsvPutBitArrElemsvPutLogicArrElemsvScalarsvSizeOfBitPackedArrsvSizeOfLogicPackedArrsv_CANONICAL_SIZEsv_CANONICAL_SIZE(WIDTH sv_handlesv_xsv_z testbenchtypedef typedefedunpredictabilityunsizedw=width   EquationVariablesҨV 8 9 ; < > ? C D G H J K M N U V Z [ a b i j m n u v ɳ    Ȯq  ѿ      ū[3  9 : = > @ A C D H U V Y Z \ ] _ ` f g j k m n p q   ! ! " " # # :72161: H3,1.1.1: 1.3.3 Special properties pure and context ;55701: H3,1.1.1: 1.4.2 Equivalence of external declarations! &82330: H3,1.1.1: 1.4.3 Function result" :63823: H3,1.1.1: 1.5.6 Restrictions on data representation% ?88327: H3,1.1.1: 1.5.2 Argument passing by position and by name, C38768: H3,1.1.1: 1.7.1 What You Specify Is What You Get Principle- =45732: H3,1.1.1: 1.7.3 Properties/qualifiers pure and context. <18958: H2,1.1: 1.8 Exported functions [this is only a draft]      ! "# >\WH/52619: x.Annex.Heading: Annex A DirectC C-layer>\WH /52619: x.Annex.Heading: Annex A DirectC C-layer>fve #<18958: H2,1.1: 1.8 Exported functions [this is only a draft]>fv #&82330: H3,1.1.1: 1.4.3 Function result>fv #:63823: H3,1.1.1: 1.5.6 Restrictions on data representation>\WH /52619: x.Annex.Heading: Annex A DirectC C-layer>fvB#=45732: H3,1.1.1: 1.7.3 Properties/qualifiers pure and context>fv#?88327: H3,1.1.1: 1.5.2 Argument passing by position and by name>fv#;55701: H3,1.1.1: 1.4.2 Equivalence of external declarations>fv0#;55701: H3,1.1.1: 1.4.2 Equivalence of external declarations>fv#C38768: H3,1.1.1: 1.7.1 What You Specify Is What You Get Principle>\WH/52619: x.Annex.Heading: Annex A DirectC C-layer-<$lastpagenum><$monthname> <$daynum>, <$year>"<$monthnum>/<$daynum>/<$shortyear>;<$monthname> <$daynum>, <$year> <$hour>:<$minute00> <$ampm>"<$monthnum>/<$daynum>/<$shortyear><$monthname> <$daynum>, <$year>"<$monthnum>/<$daynum>/<$shortyear> <$fullfilename> <$filename> <$paratext[ChapterTitle]> <$paratext[SectionTitle]> <$curpagenum> <$paranumonly[Chapter]><$paranum[Chapter]> (continued)+ (Sheet <$tblsheetnum> of <$tblsheetcount>)Heading & Page<$paratext> on page<$pagenum>Pagepage<$pagenum>See Heading & Page%See <$paratext> on page<$pagenum>. Table All7Table<$paranumonly>, <$paratext>, on page<$pagenum>Table Number & Page'Table<$paranumonly> on page<$pagenum> Draft Number (Draft 1) Draft_titleStd P 1364.1-1999 (Draft 2)copy2002std#SystemVerilog 3.1/draft 2VerilogXL version #VerilogXL 1.5c $paranumonly<$paranumonly>Section & Page%section<$paranum> on page<$pagenum>section number <$paranum>Appendix <$paranum> SeeSectForSee Section<$paranum> for SeeSectForInfo.See Section <$paranum> for more information on seeSection(see <$paranum>)Refer to TableRefer to<$paranum> Sectionsection<$paranum> SeeSecForInfo+See Section<$paranum> for more information Defined inDefined in Section<$paranum>.Table <$paranum>$paranum <$paranum>ASection<$paranum[Section,SubSection]> SectionOnly <$paranum> $paratext <$paratext> Chapter num <$paranum> SubSectionSection<$paranum> See HeadingSee <$paratext>  C_layer.fmAAA!!##&&((**A--A00A225577;9ABBDDF@AJJAMVHTMLYYHeadingsiiTOClAA ? ? ? ?@AAAA AAAA#AA%A'A)A-A!A1A3A5A9A+A.A/A;A=A?ACA7AEAGAIAMAAAOAQASAWAKAYA[A]AaAUAcAeAgAkA_AmAoAqAuAiAyA{A}AAsAvAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A A AAA ? ?@AAA A$AA&A*A"A,A0A(A2A?A.A A? C? E?5@AACAGA=AIAKAOAEAQASAWAMAYA[A_AUAaAcAgA]AiAkAoAeAqAsAwAmAyA{AAuAAAA}A ? ?@AAAAAAAAAAAAAAA ? ? ?@AAAAAAAA ? ?@AAAAAAAAAAAAAAAAAAAAAAAA Z? \?@ABAA#CA%A)D!A+A/D'A1A5D-A7A`I3AaE_kFyGTFGHIE{J Section 1EUHIEEFHGEEKV8EIE{K1.1 jERHE{EzEEhL1.1.1 E_EEE#L1.1.2 $EoEGK1.2 EML1.2.1 #E7E]L1.2.2 QE8E;EK1.3 *M EL1.3.1 EL1.3.2 EEL1.3.3 EENNNEEE4E9EML1.3.4 KEOK1.4 EIEEE EE^E_EpEEEEmPePPPPPP P~PPPPPPPP&PL1.4.1 EL1.4.2 9EWEXEL1.4.3 E4N5NEL1.4.4 ƒEnNoNpNL1.4.5 EE»EEEPPkPmPnPpPqPrPEKPűPLPE-PqP.P/P0P1P2P3P4P5P6PL1.4.6 EE%L1.4.7 EQK1.5 EѶL1.5.1 ѷEѻL1.5.2 ѼEK1.6 MEόE%E9E<EkL1.6.1 EEEL1.6.2 E+E*L1.6.3 &EɢR1.6.3.1 ɣEEN؀NNER1.6.3.2 EEEEOK1.7 S&E SE1P2E3EPPPPP_EoHUUUUUUUUUHIHILWMXNYOZP[Q\R]SEVHdKdbUBIJ.1>h h h} K L/GeHTML Mapping Table } K L/Ge } K L/Ge } K L/Ge } K L/Ge }. K .L/G eFrameMaker Source Item }~ K ~L/Ge HTML Item }6 K6L/Ge }-. K -.L/g%Include EAuto# }?. K ?.L/G e Comments } KL/Ge }H KHL/G eElement }6 K6L/g %New Web EPage? }- K-L/G e }? K?L/Ge } KL/GeP:Body }H KHL/GeP }6 K6L/GeN }- K-L/GeN }? K?L/Ge }, K,L/Ge P:Bulleted }H, KH,,L/eLI e Parent = UL Ae Depth = 0 }6, K6,L/GeN }-, K-,L/GeN }?, K?,L/Ge } KL/G!e P:CellBody }H K HL/GeP }6 K!6L/GeN }- K "-L/GeN }? K!#?L/Ge } K"$L/G&eP:CellHeading }H K#%HL/G eP }6 K$&6L/G"eN }- K%'-L/G#eN }? K&(?L/G$e } K')L/G+e P:Footnote }H K(*HL/G%eP }6 K)+6L/G'eN }- K*,-L/G(eN }? K+-?L/G)e } K,.L/ G0e P:Heading1 }H K-/HL/ G*eH* }6 K.06L/ G,eN }- K/1-L/ G-eN }? K02?L/ G.e } K13L/ G5e P:Heading2 }H K24HL/ G/eH* }6 K356L/ G1eN }- K46-L/ G2eN }? K57?L/ G3e } K68L/ G:eP:HeadingRunIn }H K79HL/ G4eH* }6 K8:6L/ G6eN }- K9;-L/ G7eN }? K:<?L/ G8e }, #K;=,L/ G?e P:Indented }H, %K<>H,,L/ 9eP @e Parent = UL AAe Depth = 0 }6, 'K=?6,L/ G;eN }-, )K>@-,L/ G<eN }?, +K?A?,L/ G=e } 4K@BL/ GFeP:Mapping Table Cell }H 6KACHL/ G>eP }6 8KBD6L/ GBeN }- :KCE-L/ GCeN }? <KDF?L/ GDe } CKEGL/GKeP:Mapping Table Title }H EKFHHL/GEeP }6 GKGI6L/GGeN }- IKHJ-L/GHeN }? KKIK?L/GIe }, RKJL,L/GPe P:Numbered }H, TKKMH,,L/JeLI Qe Parent = OL ARe Depth = 0 }6, VKLN6,L/GLeN }-, XKMO-,L/GMeN }?, ZKN?,L/GNe }, cNQ,O/GWe P:Numbered1 }H, eNPRH,,O/OeLI Xe Parent = OL AYe Depth = 0 }6, gNQS6,O/GSeN }-, iNRT-,O/GTeN }?, kNSU?,O/GUe } tNTVO/G^eP:TableFootnote }H vNUWHO/GVeP }6 xNVX6O/GZeN }- zNWY-O/G[eN }? |NXZ?O/G\e } NY[O/Gce P:TableTitle }H NZ\HO/G]eH* }6 N[]6O/G_eN }- N\^-O/G`eN }? N]_?O/Gae } N^`O/GheP:Title }H N_aHO/GbeH* }6 N`b6O/GdeN }- Nac-O/GeeN }? Nbd?O/Gfe } NceO/Gme C:Emphasis }H NdfHO/GgeEM }6 Neg6O/GieN }- Nfh-O/GjeN }? Ngi?O/Gke } NhjO/GreC:EquationVariables }H NikHO/GleEM }6 Njl6O/GneN }- Nkm-O/GoeN }? Nln?O/Gpe } NmoO/GweX:Heading & Page }H NnpHO/GqeHeading }6 Noq6O/GseN }- Npr-O/GteN }? Nqs?O/Gue } NrtO/G|eX:Page }H NsuHO/GveHeading }6 Ntv6O/GxeN }- Nuw-O/GyeN }? Nvx?O/Gze } NwyO/GeX:See Heading & Page }H NxzHO/G{e See Also }6 Ny{6O/G}eN }- Nz|-O/G~eN }? N{}?O/Ge } N|~O/Ge X:Table All }H N}HO/Ge Table All }6 N~6O/GeN }- N-O/GeN }? N?O/Ge } NO/G eX:Table Number & Page }H NHO/g%Table ENumber }6 N6O/GeN }- N-O/GeN }? N?O/G e } N O0GeHTML Options Table } N O0G e } N O0G e } N O0GeControl } N O0G eValue }H N HO0Ge Comments } N O0Ge Image Format } N O0Ge0001IMAGGIF GIF }H NHO0Ge } #NO0Ge!Copy Files Imported by Reference } %NO0GeN }H 'NHO0Ge } ,NO0GeExport Encoding } .NO0Ge ISO-8859-1 }H 0NHO0Ge } 5NO0 GeCSS Export Encoding } 7NO0 Ge ISO-8859-1 }H 9NHO0 Ge } >Q R1!G!eSystem Macros } @Q R1!Ge } BQ R1!Ge } DQ R1!G e }h GQhR1"G%e Macro Name }h IQhR1"Ge Replace With }h KQ hR1"G"eHead }B MQ!BR1"G#e Comments }h, SQ "h,R1#G)e StartOfDoc }h, UQ!#h,R1#G$e }h, WQ"$h,,R1#g&% ��<$defaulttitle></��ETITLE> }��B,�� Y�Q#%����B,R1�#G'��e }��h�� _�Q$&����hR1�$�G-��e EndOfDoc }��h�� a�Q%'����hR1�$G(��e }��h�� c�Q&(����hR1�$G*��e }��B�� e�Q')����BR1�$G+��e }��h,�� k�Q(*����h,R1�%�G1��eStartOfSubDoc }��h,�� m�Q)+����h,R1�%G,��e }��h,�� o�Q*,����h,,R1�%g.��%<TITLE> ��<$defaulttitle></��ETITLE> }��B,�� q�Q+-����B,R1�%G/��e }��h�� w�Q,.����hR1�&�G5��e EndOfSubDoc }��h�� y�Q-/����hR1�&G0��e }��h�� {�Q.0����hR1�&G2��e }��B�� }�Q/1����BR1�&G3��e }��h,�� �Q02����h,R1�'�G9��eStartOfFirstSubDoc }��h,�� �Q13����h,R1�'G4��e }��h,�� �Q24����h,,R1�'g6��%<TITLE> ��<$defaulttitle></��ETITLE> }��B,�� �Q35����B,R1�'G7��e }��h�� �Q46����hR1�(�G=��eEndOfFirstSubDoc }��h�� �Q57����hR1�(G8��e }��h�� �Q68����hR1�(G:��e }��B�� �Q79����BR1�(G;��e }��h,�� �Q8:����h,R1�)�GA��eStartOfLastSubDoc }��h,�� �Q9;����h,R1�)G<��e }��h,�� �Q:<����h,,R1�)g>��%<TITLE> ��<$defaulttitle></��ETITLE> }��B,�� �Q;=����B,R1�)G?��e }��h�� �Q<>����hR1�*�GE��eEndOfLastSubDoc }��h�� �Q=?����hR1�*G@��e }��h�� �Q>@����hR1�*GB��e }��B�� �Q?A����BR1�*GC��e }���� �� �Q@D������ R2�+�GH��eCross-Reference Macros }���� �� �Q�������� R2�+GF��e }���� �� �Q�������� R2�+GG��e }������ �QAE������R2�,�GK��e Macro Name }������ �QDF������R2�,GD��e Replace With }��?�� �QEG����?R2�,GI��e Comments }������ �QFH������R2�-�GN��eHeading }������ �QGI������R2�-GJ��e <$paratext> }��?�� �QHJ����?R2�-GL��e }������ �QIK������R2�.�GQ��e See Also }������ �QJL������R2�.GM��eSee <$paratext>. }��?�� �QKM����?R2�.GO��e }������ �QLN������R2�/�GT��e Table All }������ �QMO������R2�/gP��%Table <$paranumonly>, ��E <$paratext> }��?�� �QNP����?R2�/GR��e }������ �QOQ������R2�0�GW��e Table Number }������ �QPR������R2�0GS��eTable <$paranumonly> }��?�� �QQ�����?R2�0GU��e }���� �� �T�W������ U3�1�G[��eGeneral Macros }���� �� �T�������� U3�1GX��e }���� �� �T�������� U3�1GY��e }���� �� �T�������� U3�1GZ��e }��ev�� �TSX����evU3�2�G_��e Macro Name }��ev�� �TWY����evU3�2GV��e Replace With }��C�� �TXZ����CU3�2G\��eHead }��Q�� �TY[����QU3�2G]��e Comments }��ev�� �TZ\����evU3�3�Gc��e }��ev�� �T[]����evU3�3G^��e }��C�� ��T\^����CU3�3G`��e }��Q�� �T]_����QU3�3Ga��e }���� �� �T^b������ U4�4�Gf��eCharacter Macros }���� �� �T�������� U4�4Gd��e }���� �� �T�������� U4�4Ge��e }��H�� �T_c����HU4�5�Gi��e Character }������ �Tbd������U4�5Gb��e Replace With }��?�� �Tce����?U4�5Gg��e Comments }��H�� �Tdf����HU4�6�Gl��e }������ �Teg������U4�6Gh��e¢ }��?�� �Tfh����?U4�6Gj��e }��H�� !�Tgi����HU4�7�Go��e }������ #�Thj������U4�7Gk��e© }��?�� %�Tik����?U4�7Gm��e }��H�� *�Tjl����HU4�8�Gr��e }������ ,�Tkm������U4�8Gn��e® }��?�� .�Tln����?U4�8Gp��e }��H�� 3�Tmo����HU4�9�Gu��e }������ 5�Tnp������U4�9Gq��e° }��?�� 7�Toq����?U4�9Gs��e }��H�� <�Tpr����HU4�:�Gx��e }������ >�Tqs������U4�:Gt��e-- }��?�� @�Trt����?U4�:Gv��e }��H�� E�Tsu����HU4�;�G{��e }������ G�Ttv������U4�;Gw��e- }��?�� I�Tuw����?U4�;Gy��e }��H�� N�Tvx����HU4�<�G~��e }������ P�Twy������U4�<Gz��e... }��?�� R�Tx�����?U4�<G|��e }��h�� �� W�W�}����h�� X5�=�G��eHeadings Table }��h�� �� Y�W������h�� X5�=G��e }��h�� �� [�W������h�� X5�=G���e }��l�� ^�Wz~����lX5�>�G��eHeading Level }��u�� `�W}����uX5�>G}��eParagraph Format }��H�� b�W~�����HX5�>G��e Comments }��l�� g�W����lX5�?�G��e1 }��u�� i�W�����uX5�?G ��eTitle }��H�� k�W����HX5�?G��e }��l�� p�W����lX5�@�G ��e2 }��u�� r�W����uX5�@G UT��e Heading1 }��H�� t�W����HX5�@G��e }��l�� y�W����lX5�A�G ��e3 }��u�� {�W����uX5�AG !��e Heading2 }��H�� }�W ����HX5�AG ��e }��l�� �W ����lX5�B�G��e4 }��u�� �W ����uX5�BG !��e HeadingRunIn }��H�� �W ����HX5�BG��e }��l�� �W ����lX5�C�G��e4 }��u�� �W ����uX5�CG!��e TableTitle }��H�� �W �����HX5�CG��e U�$���� �����U�$��������������0��` Accellera Qt��h?�OSystemVerilog 3.1/draft 2�PExtensions to Verilog-2001 U�$����L����U�$���������l��� U�w��R�� �����U�w��R������������W��hQ�Q4�RCopyright �S2002�T Accellera. All rights reserved.�U�V U�w��R��N���U�w��R�������l��� U�H��ˆ���� �����U�H��ˆ��������������G��e U�H��ˆ����P����U�H��ˆ���������l��� ���~��c�������~���������"� U�H��ˆ���� �����U�H��ˆ��������������G/��e U�H��ˆ����d���U�H��ˆ����� ����l��� U�$���� �����U�$�����������������` Accellera Q^��h?Extensions to Verilog-2001�6SystemVerilog 3.1/draft 2�7 U�$����f���U�$����� ����l��� U�w��R�� �����U�w��R������������W��hQ�8�9Copyright �:2002�; Accellera. All rights reserved.�<5�= U�w��R��h����U�w��R��� ����l�����d������z��������#�������� ���~��{�������~���������"� Zl��d���� �����Zl��d��������������G$��e Zl��d����|�!��Zl��d����� ����l��� U�$���� �����U�$����������!����G��e U�$����~�#��U�$�����  ����l��� Zw��R�� �����Zw��R��������#����G�m^�Running H/F 4�Copyright �2002� Accellera. All rights reserved.�#� Zw��R���!���Zw��R���""  ����l�����d��������������&*�������� U�$���� �$����U�$����������&�����e Accellera A&�m&�SystemVerilog 3.1/draft 2�  U�$�����$�(��U�$�����%% ����l��� U�w��R�� �$����U�w��R��������(�����m^� #� Copyright � 2002�  Accellera. All rights reserved.� Running H/F 4� A,��e U�w��R���$&*��U�w��R���'' ����l��� U�H��ˆ���� �$����U�H��ˆ����������*����G��e U�H��ˆ�����$(���U�H��ˆ�����)) ����l�����d��������������--�������� U�H��ˆ���� �+����U�H��ˆ����������-����G4UT��e U�H��ˆ�����+����U�H��ˆ�����,,  ����l�����d��������������02�������� U�H��ˆ���� �.����U�H��ˆ����������0����G��e U�H��ˆ�����.�2��U�H��ˆ�����//����l��� U�8I��6z�� �.����U�8I��6zJ� ��� ��2���� 5��"m�> _��e `��e1Copyright 2002 by Accellera Organization, Inc. a��e1370 Trancas Street #163 b��eNapa, CA 94558 c��ePhone: (707) 251-9977 d��eFax: (707) 251-9877 e��e f��e ag��%cAll rights reserved. No part of this document may be reproduced or distributed in any medium what��EZsoever to any third parties without prior written consent of Accellera Organization, Inc. U�8I��6z���.0���U�8I��6z���11����l�����d��������������5<�������� U�$���� �3����U�$����������5����!�e Accellera Ah�m?�?SystemVerilog 3.1/draft 2�@Extensions to Verilog-2001 U�$�����3�7��U�$�����44 ����l��� U�w��R�� �3����U�w��R��������7����"�m^�A#�BCopyright �C2002�D Accellera. All rights reserved.�ERunning H/F 4�F Ai��e U�w��R���359��U�w��R���66 ����l��� D�:Hˆ���� �3����D�:Hˆ�������������9�����D�:Hˆ�����37;<�;�D�:Hˆ���;�88 ����l��� U�Hˆ���� �3����U�Hˆ����������;����G#��e U�Hˆ�����39<<9��U�Hˆ����9:: ����l���U�Hˆ�����3;���U�Hˆ��9;��d��������������>G�������� ���~���=�@�����~���������"� D�:Hˆ���� �=����D�:Hˆ�������������@�����D�:Hˆ�����=>BG�F�D�:Hˆ���F�??����l��� U�$���� �=����U�$����������B����%��e Accellera Aj�m?Extensions to Verilog-2001�GSystemVerilog 3.1/draft 2�H U�$�����=@D��U�$�����AA����l��� U�w��R�� �=����U�w��R��������D����'�m^�IRunning H/F 4�JCopyright �K2002�L Accellera. All rights reserved.�M#�N Ak��e U�w��R���=BF��U�w��R���CC����l��� U�Hˆ���� �=����U�Hˆ����������F����G(��e U�Hˆ�����=DGG@��U�Hˆ����@EE����l���U�Hˆ�����=F���U�Hˆ��@F��d��������������JJ �������� U�H��ˆ���� �H����U�H��ˆ����������J����G)��e U�H��ˆ�����H����U�H��ˆ�����II ����l�����d��������������MM �������� $$������ �K����$$������-���OM��-PUZ_dinsx} !%)-159=ADGJMPSW[_behknqtw�G1��Bm�/�0�1�2�3�4 $$�������K����$$�����PLL ����l�����d��������������PP �������� $$������ �N����$$�����������PP�PUZ_dinsx} !%)-159=ADGJMPSW[_behknqtw��$$�������N����$$����MSOO����l�����d���������������SS �������� $$������ �Q����$$�������� ���RS�!%)-159=ADGJMP SW[_behknqtw��$$�������Q����$$����PVRR ����l�����d��������������VV �������� $$������ �T����$$�������� ����SyV� SW[_behknqtw���$$�������T����$$����S�UU����l�����d������ ��������YY�������� $$h������ �W����$$h����������zY����G+��Bm�5 $$h������ �W����$$h������XX ����l�����d������:��������[f�������� HwpKe��;�Z�\��HwpKeHRHR�#Footnote Hoe��<�Z[]��HoeHzHz�# Single LineH'����=�Z\_����^^��������Footnote$���>�]����$��% HDfe��?�Z]`��HDfeHH�# Double LineH���� ��@�Z_c����ab�������� Double Line������A� `�b����������������B� `a�����������H���� ��C�Z`e����dd�������� Single Line������D� c������������HZ����E�Zcf�������������� TableFootnote EE;Rbe��F�Ze���EE;RbeEPlEPl�# TableFootnote��d������H��������ii�������� HH��ˆ���� �g����HH��ˆ��� ��� ����i����*6�e"<$paranum><$paratext><$pagenum> l�e#<$paranum><$paratext><$pagenum> m�e#<$paranum><$paratext><$pagenum> n�e#<$paranum><$paratext><$pagenum> o�e$<$paranum><$paratext><$pagenum> p�e#<$paranum><$paratext><$pagenum> q�e"<$paranum><$paratext><$pagenum> r�e"<$paranum><$paratext><$pagenum> Cs��e HH��ˆ����I�g����HH��ˆ�����hh ����l�����d�������(��������ll�������� U�H��ˆ���� �j����U�H��ˆ��w�D.���.����l����UTUT���  UR���@DirectC interface -��� pThis chapter highlights the DirectC interface and provides a detailed description of the SystemVerilog-layer of ���H<the interface. The C-layer is defined in �Annex A�. . UT[UN���` Introduction 2s��� lThe DirectC interface is an interface between SystemVerilog and a foreign programming language. It consists 0~����oof two separated layers: the SystemVerilog-layer and a foreign language layer. Both sides of the DirectC inter����lface are fully isolated. Which programming language is actually used as the foreign language is transparent ���wand irrelevant for the SystemVerilog side of this interface. Neither of the two  $tools  (the SystemVerilog com����rpiler or the foreign language compiler) is required to analyze the source code in the others language. Different ����gprogramming languages can be used and supported with the same intact SystemVerilog-layer. For now, how���tever, SystemVerilog 3.1 defines a foreign language layer only for the C programming language. See �Annex A� ���@for more details. 3ժ��� qThe motivation for this interface is two-fold. The methodological requirement is that the interface should allow 0ઙ����kto build a heterogeneous system (a design or a testbench) in which some components may be written in a lan����jguage (or more languages) other than SystemVerilog, hereinafter called the foreign language. On the other ����thand, there is also a practical need for an easy and efficient way to connect the existing code, usually written in ����kC or C++, without the knowledge and the overhead of PLI or VPI. In the simplest typical scenario, a System����oVerilog design and/or a testbench is used in the non-Verilog environment (file system, etc.), which is usually ���@&programmed in C or accessible via C. 4,��� nThe DirectC interface follows the principle of a black box: the specification and the implementation of a com07����sponent is clearly separated and the actual implementation is transparent to the rest of the system. Therefore, the ����kactual programming language is also transparent. The separation between SystemVerilog code and the foreign ����klanguage is based on using functions as the natural encapsulation unit in SystemVerilog. By and large, any ����ofunction can be treated as a black box and implemented either in SystemVerilog or in the foreign language in a ���@-transparent way, without changing its calls. 5 z���` Functions 6��� pThe DirectC interface allows direct function calls from the other language on either side of the interface. Spe0����lcifically, functions implemented in a foreign language can be called from SystemVerilog; such functions are ����xreferred to as  %external functions . SystemVerilog functions that are to be called from a foreign code shall be ���specified in  &export  declarations (see �section1.7� for more details). The DirectC interface allows for passing ����iSystemVerilog data between the two domains through function arguments and results. There is no intrinsic ���@overhead in this interface. 7ܪ��� zAll functions used in the DirectC interface are assumed to complete their execution instantly and take  &0  (zero) 0窅��wsimulation time.  (emove: In particular, the external functions shall be non-blocking (execute in zero-simula��ution time) and contain no timing control. (]  DirectC provides no means of synchronization other than by data ���@+exchange and explicit transfer of control. 8��� wEvery external function needs to be declared. A declaration of an external function is referred to as an  'external '����udeclaration . External declarations are very similar to SystemVerilog function prototypes. External declarations "����{shall occur only at the top level, i.e., in the  &$root  scope. Multiple declarations of the same external function ����are allowed as long as they are equivalent. External functions can have zero or more formal  &input ,  &output , ���@gand  &inout  arguments, and they can return a result or be defined as  &void  functions. 9S}��� oThe DirectC interface is entirely based upon SystemVerilog constructs. The usage of external functions is idenp^|����qtical as for native SystemVerilog functions. With few exceptions the external functions and the native functions ����nare mutually exchangeable. Calls of external functions are indistinguishable from calls of SystemVerilog func���@Itions. This facilitates an ease-of-use and minimizes the learning curve. U�H��ˆ�����(�j����U�H��ˆ����okk ����l�����d������}��������oo�������� U�H��ˆ���� �m����U�H��ˆ��M�*���*����o����: ���` Data types ;��� mSystemVerilog data types are the sole data types that can cross the boundary between SystemVerilog and a for0����ieign language in either direction (i.e., when a foreign function is called from SystemVerilog code or an ����oexported SystemVerilog function is called from a foreign code). It is not possible to import the data types or ����idirectly use the type syntax from another language. With with some restrictions and with some notational ����jextensions, most SystemVerilog data types are allowed in the DirectC interface. Function result types are ���HCrestricted to small values, however (see �section1.4.3�). <h��� wFormal arguments of an external function can be specified as open arrays. A formal argument is an  %open array  0s����kwhen a range of one or more of its dimensions, packed or unpacked, is unspecified (denoted by using square ����ybrackets ( &[] )). This is solely a relaxation of the argument-matching rules. An actual argument shall match the ����oformal one regardless of the range(s) for its corresponding dimension(s), which facilitates writing a more gen���H`eral code that can handle SystemVerilog arrays of different sizes. See �section1.4.6�. = UTUH���`$Two layers of the DirectC interface >ʪ��� mThe DirectC interface consists of two separate layers: the SystemVerilog-layer and a foreign language layer. 0ժ����jThe SystemVerilog-layer does not depend on which programming language is actually used as the foreign lan����hguage. Although different programming languages can be supported and used with the intact SystemVerilog-����mlayer, SystemVerilog 3.1 defines a foreign language layer only for the C programming language. Nevertheless, ���@mSystemVerilog code shall look identical and its semantics shall be unchanged for any foreign language layer. ? ���`DirectC SystemVerilog-layer @#��� hThe SystemVerilog side of the DirectC interface does not depend on the foreign programming language. In 0.����oparticular, the actual function call protocol and argument passing mechanisms used in the foreign language are ����mtransparent and irrelevant to SystemVerilog. SystemVerilog code shall look identical regardless of what code ����pthe foreign side of the interface is using. The semantics of the SystemVerilog side of the interface is indepen���@-dent from the foreign side of the interface. Ad��� pThis chapter does not constitute a complete interface specification. It only describes the functionality, seman0o����stics and syntax of the SystemVerilog-layer of the interface. The other half of the interface, the foreign language ����mlayer, defines the actual argument passing mechanism and the methods to access (read/write) formal arguments ���H9from the C code. See �Annex A� for more details. B ���`DirectC foreign language layer C��� mThe foreign language layer of the interface (which is transparent to SystemVerilog) shall specify how actual 0����larguments are passed, how they can be accessed from the foreign code, how SystemVerilog-specific data types ����~(such as  &logic  and  &packed ) are represented, and how to translated them to and from some predefined C-like ���@types. D誈��� pThe data types allowed for the formal arguments and results of the external functions or exported functions are 0����kgenerally SystemVerilog types (with some restrictions and with notational extensions for open arrays). The ����puser is responsible for specifying in their foreign code the native types equivalent to the SystemVerilog types ����yused in external declarations or  export  declarations. EDA tools, like a SystemVerilog compiler, can facilitate ���@mthe mapping of SystemVerilog types onto foreign native types by generating the appropriate function headers. E)��� jThe SystemVerilog compiler or simulator shall generate and/or use the function call protocol and argument p4����fpassing mechanisms required for the intended foreign language layer. The same SystemVerilog code (com����ppiled accordingly) shall be usable with different foreign language layers, regardless of the data access method ���@assumed in a specific layer. U�H��ˆ����} �m����U�H��ˆ���lrnn����l�����d������3��������rr�������� U�H��ˆ���� �p����U�H��ˆ��}�D*���*����r����F UTUT���`*Required properties of external functions G(��0bThis section, 1.3, is aimed at foreign language programmers: what are they allowed to do in their 0��ecode, what criteria must be met by their legacy code to be hooked-up to SV, etc. In other words, the ��PEemphasis should be on what is allowed and what is not allowed.  ) HM��� jThis section defines the semantic constraints imposed on external functions. Although no specific program0X����kming language is assumed, the external functions have some semantic restrictions. A SystemVerilog compiler ����wis not able to verify that those restrictions are observed and if those restrictions are not satisfied, the effects of ���@-external function call can be unpredictable. I ��p?0-time  (reviously: Non-blocking (]  functions J��� pExternal functions shall contain no timing control whatsoever, directly or indirectly. External functions shall 0����nbe non-blocking; they shall complete their execution instantly and take zero-simulation time, i.e., no simula���@<tion time passes during the execution of external function. K&Ȫ���`*input  and  &output  arguments Lު��� External functions can have  &input  and  &output  arguments. The formal  &input  arguments shall not be mod0骛����sified. If such arguments are changed within a function, the changes shall not be visible outside the function; the ���@'actual arguments shall not be changed. M ��� wThe external function shall not assume anything about the initial values of formal  &output  arguments. The ini���@Ytial values of  &output  arguments are undetermined and implementation-dependent. N +���h8�Special properties  &pure  and  &context OA���( Special properties can be specified for an external function: as  &pure  or as  &context  (see also �section1.6.3�). 0L����zExternal functions specified as  &pure  shall have no side effects; their results need to depend solely on the val����mues of their input arguments. Calls to such functions can be removed by SystemVerilog compiler optimizations ���@\or replaced with the values previously computed for the same values of the input arguments. Pw���`uSpecifically, a  &pure  function is assumed not to directly or indirectly (i.e., by calling other functions): Q���`perform any file operations R���pBread or write anything **revise per changes to C-layer??  S���`=access any persistent data, like global or static variables. Tª��� tIf a  &pure  function does not obey the above restrictions, SystemVerilog compiler optimizations can lead to ͪ���@Nunexpected behavior, due to eliminated calls or incorrect results being used. U⪌��� rSome PLI and VPI functions require that the context of their call is known. It takes a special instrumentation of 0����ptheir call to provide such context; for example, some variables referring to the current instance or current ����otask need to be set. To avoid any unnecessary overhead, external function calls in SystemVerilog code are not ���@Minstrumented unless the external function is specified as  &context . V��� nFor the sake of simulation performance, an external function call shall not block SystemVerilog compiler opti0#����kmizations. The SystemVerilog compiler needs to be able to determine which SystemVerilog data objects might ����ube accessed (read or written) by a particular external function call. An external function not specified as  &con&����ptext  shall not access any data objects from SystemVerilog other then its actual arguments. Only the actual "����oarguments can be affected (read or written) by its call. (This rule does not prohibit the access to non-System����xVerilog data, like global C variables.) Therefore, a call of non- &context  function does not block the optimiza���@tions. Wo��� uA  &context  function, however, can access (read or write) any SystemVerilog data objects by calling PLI/VPI; Pz����xtherefore, a call to a  &context  function is a barrier for SystemVerilog compiler optimizations. Only the calls U�H��ˆ����6�p����U�H��ˆ���ouqq ����l�����d������z��������uu�������� U�H��ˆ���� �s����U�H��ˆ��‡�D,���,����u����W����tof  &context  functions are properly instrumented and cause conservative optimizations; only those functions 0����ican safely call all functions from other APIs, including PLI and VPI functions or exported SystemVerilog ���@ functions. X��� wFor functions not specified as  &context , the effects of calling PLI, VPI, or exported SystemVerilog functions 0����ncan be unpredictable and can lead to unexpected behavior, due to incorrect optimizations; such calls can even ���P3crash.  **revise per changes to C-layer??  Y ^���`Memory management Zt��� jThe memory spaces owned and allocated by the foreign code and SystemVerilog code are disjoined. Each side 0����ois responsible for its own allocated memory. Specifically, an external function shall not free the memory allo����jcated by SystemVerilog code (or the SystemVerilog compiler) nor expect SystemVerilog code to free the mem����kory allocated by the foreign code (or the foreign compiler). This does not exclude scenarios where foreign ����ncode allocates a block of memory, then passes a handle (i.e., a pointer) to that block to SystemVerilog code, ����which in turn calls a external function that directly (if it is the standard function  &free ) or indirectly frees that ���@block. [��� vNOTEIn this last scenario, a block of memory is allocated and freed in the foreign code, even when the standard func���@Wtions  &malloc  and  &free  are called directly from SystemVerilog code. \ UTUF���`External declarations ] ��� zEach external function shall be declared. Such declaration are referred to as  %external declarations . The syntax ���@Zof an external declaration is similar to the syntax of SystemVerilog function prototypes. ^,��� nAn external declaration specifies the function name, function result type, and types and directions of formal 07����garguments. It can also provide optional names and default values for formal arguments. Formal argument ����inames can be used for argument passing by name, otherwise they serve as comments and are meaningless. An ���@jexternal declaration can also specify an optional function property:  &context  or  &pure . _b��� mA declared external function eventually resolves to a global symbol of the same name defined outside the Sys0m����jtemVerilog design. Therefore, external function names need to be unique; no overloading is allowed for an ���@external function. `��� kThe names of external functions shall follow C conventions for naming. They need to be legal global names. 0����Additionally, an external function name shall not start with  &the   &$  character (to avoid clashes with system ���@tasks or functions). a��� sExternal declarations can occur only in the  &$root  scope. External declarations can occur anywhere in the &ê����u$root  scope, i.e., outside of modules, interfaces, functions, and tasks. An external declaration of an external ���@Cfunction need not precede an invocation of that external function. b㪋��� oThe scope of an external declaration is the whole design. A name of external function shall not clash with any 0����wname declared in the  &$root  scope. Regular name resolving rules apply to external functions. Therefore, local ����jnames declared inside a module (or interface) shall obscure external function names; qualified names like &���Pq$root.xf_name  can be used to resolve a name to a name  $declared in the  &$root *  $scope . c��� kExternal functions are similar to SystemVerilog functions. External functions can have zero or more formal &$����input ,  &output ,  and  &inout  arguments. External functions can return a result or be defined as  &void  func���@tions. dD��� wFunction declarations default to the formal direction  &input  if no direction has been specified. Once a direc0O����otion is given, subsequent formals default to the same direction. Default data types are not allowed; data type ���@need to be explicitly given. eo���`cA formal argument name is required to separate the packed and the unpacked dimensions of an array. Af��� tThe qualifier  &ref  can not be used in external declarations. The actual implementation of argument passing U�H��ˆ����}�s����U�H��ˆ���rxtt����l�����d��������������xx�������� U�H��ˆ���� �v����U�H��ˆ��^�D,���,����x����f����ndepends solely on the foreign language layer and its implementation and shall be transparent to the SystemVer0����ilog side of the interface. Specifically, an actual argument can be passed  %by value  or  %by reference  depending on ���@8the direction and the data type of the formal argument. g���`5The following are examples of external declarations. h ���` iF���`extern void myInit(); j���`// from standard math library k���`extern pure real sin(real); l���`.// from standard C library: memory management m���`7extern handle malloc(int size); // standard C function n���`5extern void free(handle ptr); // standard C function o���`"// abstract data structure: queue p���` extern handle newQueue(string); q���`Nextern handle newQueue(input string name_of_queue); // equivalent declaration r���`#extern handle newElem(bit [15:0]); s���`0extern void enqueue(handle queue, handle elem); t���`%extern handle dequeue(handle queue); u���`// miscellanea v���`!extern bit [15:0] getStimulus(); w���`4extern context void processTransaction(handle elem, x��`(output logic [64:1] arr [0:63]); y ���`Multiple declarations z��� pAn external function can have multiple declarations (i.e., declarations with the same function name) as long as 0$����othey are all equivalent. This allows building a design from several components that use the same external func���@Otion; each component containing its own external declaration of that function. { F���h*�Equivalence of external declarations |\��� nTwo declarations are equivalent if they specify the same function result type, the same number of formal argug����iments, and for each formal argument respectively, the same direction and equivalent types. SystemVerilog $���wtypes  equivalence rules shall be applied. If a default value is specified for a formal argument, the same default "����value shall be specified in both declarations. If the function property  &context  or  &pure  is specified, both dec���@+larations shall specify the same property. }$���0kThe optional names of formal arguments are irrelevant, with the exception of functions where argument pass0���ing by name is used (see  �section1.5.2�  $). Two declarations can use different names for the same formal argu���PWment or have that argument unnamed, and do so independently for each declaration. + ~Ȫ���0xAn external function is termed  %unambiguously defined $ if for every formal argument of that function either all 0Ӫ���nexternal declarations of that function define the same name or none of them define a name of that formal argu���P_ment. This is required only for functions which are called with arguments passed by name. +  ���h�!Function result � ��� mFunction result types are restricted to small values. The following SystemVerilog data types are allowed for &���@ external  function results: '���`(void ,  &char ,  &byte ,  &shortint ,  &int ,  &longint ,  &real ,  &shortreal ,  &handle , and  &string 9��0packed  &bit  arrays up to  *64   (reviously 32]  bits and all types that are eventually equivalent to packed  &bit  E���P arrays up to  *64  bits. Q[���`HThe same restrictions apply for the result types of exported functions. U�H��ˆ�����v����U�H��ˆ���u{ww ����l�����d��������������{{�������� U�H��ˆ���� "�y����U�H��ˆ��u�D/���/����{���� ���`Types of formal arguments ��� kWith some restrictions and with notational extensions, all SystemVerilog data types are allowed for formal ���@!arguments of external functions. $���0iEnumerated data types are not supported directly. Instead, an enumerated data type is interpreted as the D���P0type associated with that enumerated type. + V���0dSystemVerilog does not specify the actual memory representation of packed structures or any arrays, 0b���dpacked or unpacked. Unpacked structures have an implementation-dependent packing, normally matching ���Pthe C compiler. + ���0hThe actual memory representation of SystemVerilog data types is transparent for SystemVerilog semantics 0���mand irrelevant for SystemVerilog code. It can be relevant for the foreign language code on the other side of ���ithe interface, however; a particular representation of the SystemVerilog data types can be assumed. This ���gshall not restrict the types of formal arguments of external functions, with the exception of unpacked ���darrays. SystemVerilog implementation can restrict which SystemVerilog unpacked arrays are passed as ���iactual arguments for a formal argument which is a sized array, although they can be always passed for an ���eunsized (i.e., open) array. Therefore, the correctness of an actual argument might be implementation-���P]dependent. Nevertheless, an open array provides an implementation-independent solution. +  쪚���` Open arrays  ��� jThe size of the packed dimension, the unpacked dimension, or both dimensions can remain unspecified; such 0 ����ycases are referred to as  %open arrays  (or unsized arrays). These arrays allow the use of generic code to handle ���@different sizes.  -��� jFormal arguments of external functions can be specified as open arrays. (Exported SystemVerilog functions 08����ucannot have formal arguments specified as open arrays.) A formal argument is an  %open array  when a range of ����wone or more of its dimensions is unspecified (denoted by using square brackets ( &[] )). This is solely a relax����oation of the argument-matching rules. An actual argument shall match the formal one regardless of the range(s) ����lfor its corresponding dimension(s), which facilitates writing a more general code that can handle SystemVer���@!ilog arrays of different sizes.  y��� lAlthough the packed part of an array can have an arbitrary number of dimensions, in the case of open arrays 0����ponly a single dimension is allowed for the packed part. This is not very restrictive, however, since any packed ����htype is eventually equivalent to one-dimensional packed array. The number of unpacked dimensions is not ���@ restricted.  ���0rIf a formal argument is specified as an open array  $with a range of its packed or one or more of its unpacked $���pdimensions unspecified , then the actual argument shall match the formal one regardless of its dimensions ���sand sizes of its linearized packed or unpacked dimensions  $corresponding to an unspecified range of the formal $���Pargument , respectively. 媈���`hHere are examples of types of formal arguments (empty square brackets  &[]  denote open array):  ���` ���`logic ���` bit [8:1] ���`bit[] ���`6bit [7:0] b8x10 [1:10] // b8x10 is a formal arg name ���`3logic [31:0] l32x [] // l32x is a formal arg name ���`0logic [] lx3 [3:1] // lx3 is a formal arg name ���`Ebit [] an_unsized_array [] // an_unsized_array is a formal arg name R���p5Example  $of complete external declarations :  \���` g���`&extern void foo(input logic [127:0]); A��`Dextern void boo(input logic [127:0] i []);// open array of 128-bit U�H��ˆ�����y����U�H��ˆ���x~zz����l�����d��������������~~�������� U�H��ˆ���� &�|����U�H��ˆ��‡�D*���*����~����$���paThe following example shows the use of open arrays for different sizes of actual arguments :  ���` ���`%typedef struct {int i; ... } MyType; ���` ��`Qextern void foo(input MyType i [][]); /* 2-dimensional unsized unpacked array  ���`7of MyType */ !���` "��`MyType a_10x5 [11:20][6:2];  #���`MyType a_64x8 [64:1][-1:-8]; $���` %��`foo(a_10x5);  &���` foo(a_64x8); ' ���h)�"Restrictions on data representation (��� iThe DirectC interface does not add any constraints on how SystemVerilog-specific data types are actually 0����mimplemented. Optimal representation can be platform dependent. The layout of 2- or 4-state packed structures ���@6and arrays is implementation- and platform-dependent. )ת��� oThe implementation (representation and layout) of 4-state values, structures, and arrays is irrelevant for Sys⪤���PWtemVerilog semantics, and  $can only  impact the foreign side of the interface. * ���`Syntax of external declaration +��� oThe syntax of an external declaration is based on SystemVerilog syntax for functions, with an ANSII style port ���@%list, cf.  ,LRM Section 10 . ,$*���p **Add actual syntax here** + - UTIUI���`External function calls .a��� mThe usage of external functions is identical as for native SystemVerilog functions. The usage and syntax for l���@Ocalling external functions is identical as for native SystemVerilog functions. /.���p(Default values of formal arguments / 0$���0mExternal declarations can specify a default value for each formal argument with the same restrictions as for 0���nnative SystemVerilog functions. All external declarations of a function shall specify the same default values ���(see  �#section1.4.2�$ $). When an external function is called, arguments with default values can be omitted from the ���Pjcall and the compiler shall insert their corresponding values as for native SystemVerilog functions. + 1.Ѫ���x3�%Argument passing by position and by name / 2$窕���0kSystemVerilog allows arguments to external functions to be passed by name or by position. Arguments can be ���Xopassed by name only for functions that are unambiguously defined (see  �&section1.4.2�' $). + 3 UTU=���`Argument passing 4((��0`This section, 1.6, is aimed at SV programmers. Im planning to call an external function. When 04��bshall I specify it as pure or context? Here the emphasis should be on something different. (Note ��hthat if every function is specified as context, we are on the safe side, only the performance is poor.) ��jThe situation is like this: if I specify a function as pure, Ill enable more optimizations. When is this ��Pdsafe? When I specify a function as context, Ill disable optimizations. When should I do this? ) 5n��� ~Arguments passing for external functions is ruled by  'WYSIWYG  principle:  'What You Specify Is What You Get , py���vsee �(section1.6.1�). The evaluation order of formal arguments follows general SystemVerilog rules. Directions ���@jand types of formal arguments of external functions are never coerced, regardless of the actual argument. U�H��ˆ�����|����U�H��ˆ���{}} ����l�����d������V���������������� U�H��ˆ���� *�����U�H��ˆ��c�D,���,��������6���0tArgument compatibility and coercion rules are the same as for native SystemVerilog functions.  $If a coercion is 2$���needed, a temporary variable is created and passed as the actual argument. *  For  &input  and  &inout  arguments, ���ythe  temporary variable is initialized with the value of actual argument with the appropriate coercion; for  &out&����wput  or  &inout  arguments, the value of the temporary variable is assigned to the actual argument with the "����jappropriate conversion. The assignments between a temporary and the actual argument follow general System���@7Verilog rules for assignments and automatic coercion. 7R��� sOn the SystemVerilog side of the interface, the values of actual arguments for formal  &input  arguments of 0]����yexternal functions shall not be affected by the callee; the initial values of formal  &output  arguments of exter����nnal functions are unspecified (and can be implementation-dependent), and the necessary coercions, if any, are ���@papplied as for assignments. External functions shall not modify the values of their  &input  arguments. 8��� wFor the SystemVerilog side of the interface, the semantics of arguments passing is as if  &input  arguments are ����passed by  %copy-in ,  &output  arguments are passed by  %copy-out , and  &inout  arguments were passed by  %copy-%���� in ,  %copy-out . The terms  %copy-in  and  %copy-out  do not impose the actual implementation, they refer only to ���@hypothetical assignment. 9��� lThe actual implementation of argument passing is transparent to the SystemVerilog side of the interface. In 0ɪ����particular, it is transparent to SystemVerilog whether an argument is actually passed  %by value  or  %by reference . ���oThe actual argument passing mechanism is defined in the foreign language layer. See �*Annex A�+ for more ���@ details. : ���h2�,What You Specify Is What You Get principle ; ��� kThe principle What You Specify Is What You Get guarantees the types of formal arguments of external func0����mtions an actual argument is guaranteed to be of the type specified for the formal argument, with the excep����mtion of open arrays (for which unspecified ranges are statically unknown). Formal arguments, other than open ����rarrays, are fully defined by external declaration; they shall have ranges of packed or unpacked arrays exactly as ����sspecified in the external declaration. Only the declaration site of the external function is relevant for such for���@mal arguments. <X��� lThe formal arguments defined as open arrays have the size and ranges of the actual argument, i.e., have the 0c����nranges of packed or unpacked arrays exactly as that of the actual argument. The unsized ranges of open arrays ���@fare determined at a call site; the rest of type information is specified at the external declaration. =��� wSo, if a formal argument is declared as  &bit [15:8] b [] , then it is the external declaration which specifies 0�����the formal argument is an unpacked array of packed bit array with bounds  &15  to  &8 , while the actual argument ���@Wused at a particular call site defines the bounds for the unpacked part for that call. > ���`-Value changes for output and inout arguments ?ƪ��� zThe SystemVerilog simulator is responsible for handling value changes for  &output  and  &inout  arguments. 0Ѫ���xSuch changes shall be detected and handled after the control returns from  $external functions  to SystemVerilog ���@code. @��� ~For  &output  and  &inout  arguments, the value propagation (i.e., value change events) happens as if an actual 0����oargument was assigned a formal argument immediately after control returns from external functions. If there is ����kmore than one argument, the order of such assignments and the related value change propagation follows gen���@eral SystemVerilog rules. A )���h;�-Properties/qualifiers  &pure  and  &context B?��� pThe usage of the DirectC interface shall not prohibit compiler optimizations by introducing unpredictability in pJ����maccessing and/or modifying SystemVerilog data. The ability to access Verilog data from an external function, ����sdirectly or indirectly (for example, by calling an exported function), shall be easily visible to the compiler. To ���@zfacilitate this, special properties can be specified for an external function: as  &pure  or as  &context . U�H��ˆ����Y�����U�H��ˆ���~������l�����d���������������������� U�H��ˆ���� .�����U�H��ˆ��{�D+���+���� ����C&���`pure  functions D��� {A  &pure  function call can be safely eliminated if its result is not needed or if the previous result for the same 0����jvalues of input arguments is available somehow and can be reused without needing to recalculate. Only non-����void functions with no  &output  or  &inout  arguments can be specified as  &pure . Functions specified as  &pure  ����sshall have no side effects whatsoever; their results need to depend solely on the values of their input arguments. ����kCalls to such functions can be removed by SystemVerilog compiler optimizations or replaced with the values ���@@previously computed for the same values of the input arguments. Eh���`uSpecifically, a  &pure  function is assumed not to directly or indirectly (i.e., by calling other functions): Fy���`perform any file operations G���pCread or write anything  **revise per changes to C-layer??  H���`=access any persistent data, like global or static variables. I��� tIf a  &pure  function does not obey the above restrictions, SystemVerilog compiler optimizations can lead to ���@Nunexpected behavior, due to eliminated calls or incorrect results being used. J&Ѫ���`context  functions K窜��� rSome PLI and VPI functions require that the context of their call is known. It takes a special instrumentation of 0����ptheir call to provide such context; for example, some variables referring to the current instance or current ����otask need to be set. To avoid any unnecessary overhead, external function calls in SystemVerilog code are not ���@winstrumented unless the external function is specified as  &context  in its SystemVerilog external declaration. L��� nFor the sake of simulation performance, an external function call shall not block SystemVerilog compiler opti0(����tmizations. An external function not specified as  &context  shall not access any data objects from SystemVer����oilog other then its actual arguments. Only the actual arguments can be affected (read or written) by its call. ���@YTherefore, a call of non- &context  function is not a barrier for optimizations. MS��� uA  &context  function, however, can access (read or write) any SystemVerilog data objects by calling PLI/VPI; 0^����xtherefore, a call to a  &context  function is a barrier for SystemVerilog compiler optimizations. Only the calls ����tof  &context  functions are properly instrumented and cause conservative optimizations; only those functions ����ican safely call all functions from other APIs, including PLI and VPI functions or exported SystemVerilog ����yfunctions. For functions not specified as  &context , the effects of calling PLI, VPI, or SystemVerilog functions ���@ocan be unpredictable and such calls can crash if the callee requires a context that has not been properly set. N��� vAn external function, unless declared as  &context , can access only those SystemVerilog data objects that are 0����nexplicitly passed as actual arguments to its call (it shall not access data objects that have been not passed ����vexplicitly as arguments of the particular call). An external function declared as  &context  can safely access ���Pkother SystemVerilog data objects (e.g., via VPI or PLI calls).  **revise per changes to C-layer??  O���`cNOTEThis might also require  turning on  PLI/ACC capabilities for the respective modules. P UTU4���h�.Exported functions Q$ ���0hThe DirectC interface allows calling SystemVerilog functions from another language, however, only those 0���wfunctions which satisfy the same restrictions for formal arguments and function result as  &external $ functions ���Pcan be used. + R7��� vSystemVerilog functions that can be called from a foreign code need to be specified in  &export  declarations. &B����zexport  declarations can occur only within the  &$root  scope, i.e., outside of modules, interfaces, functions ���@ and tasks. S$b���0wAn  1export $ declaration shall specify a unique instance of a module or an interface for the exported function, pm���unless the function is a global one, i.e. declared in the  &$root $ scope. An  &export $ declaration can define an ���PYoptional name to be used in the foreign language for calling the exported function. + U�H��ˆ���������U�H��ˆ��� ����l�����d���������������������� U�H��ˆ���� 2�����U�H��ˆ���T ��� ���� ����T���`Syntax: U2���`mexport_decl  ::=  2export  [ 2cname ] [ 2modulename 3:: ]  2fname   3; V���`�cname  is optional here, it defaults to  2fname  (for example, for functions defined in the  &$root  scope). W���` Example: X(E��0^[these examples have to be replaced with new ones, they dont comply with the solution agreed P��P upon] ) Y ��pNexport $root.exported_sv_func; //  (he syntax needs to be checked!] ) Z���`1export global_func; // must be defined in $roots [���`Fexport foo1 top.m1.foo; // same function from two different instances \���`>export foo2 top.m2.foo; // exported under two different names W]���` U�H��ˆ���������U�H��ˆ��������l�����d���������Left�d�������Right�d�������First�d�����$�� last left�d�����+�� boilerplate�d�����.�� title page�d�����3�� Index.left�d����� =�� Index.right�d������H��Cover�d������� K��HTML�d����� N��HTML�d����� Q��HTML�d����� T��HTML�d����� W��Headings�d�����Z�� Reference�d������g��TOC�d�������j�����d�����m�����d�����p�����d�����s�����d�����v�����d�����y�����d�����|�����d����������d����������d���� ������������ �f�@��������BE��� ������� �������������������������� Bibliography���� B:[B<n+>] �. (���f�@�������������������� �������������������������.�� =�� BNF_SyntaxItem������. ��� �f�@������������������ ��������������������������Body������. ��f�@��������������������� �������������������������(�� <�� P�� d�� x�� ���� ���� ���� ���� ���� ���� ���� ���� ,���� @���� T���� h���� |���� ���� ���� ���� ���� Body.Indented.1������. �����f�@�������������������� ��������������������������CellBody������. ����f�@��������������������� �������������������������� CellBody.X������. �����f�@������������������ ���������������� ���������� CellHeading������. �f�@���������������������� ���������������� ��������� �� comment������. ���f�@�������������������� ����������������������������� M���� CommitteeList������. ���f�@��������D������������ ��������������������������� DashedList����D:\t�. ��f�@��������D������������ ��������������������������� DashedList.indented����D:\t�. ��� �@��@��������EA��� �������� �� =�����������������������ExampleCaption����E:Example<$chapnum><n+>Body. �����f�@���������������������� ��������������������������� �� 0�� @�� P�� `�� p�� ���� ���� ���� ���� ���� ���� ���� ���� ����� ���� ���� 0���� @���� P���� `���� p���� ���� ���� ���� ���� ���� ���� ExampleCode������. ���f�@���������������������� �������������������������$�� 4�� D�� T�� d�� t�� ���� ���� ���� ���� ���� ���� ���� ���� ���� ���� $���� 4���� D���� T���� d���� t���� ���� ���� ���� ���� ���� ���� ExampleCode.Indented������. K��� f�@��������FE��� �������� ���������������� ���������� FigureCaption����F:Figure <n=1><n+>FigCaptionCont. ���f�@����������������������������������������������Footnote������. ��� f�@��������HU���������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H2,1.1���H2 H:<n>.<n+> Body. ��� f�@��������HU��� ������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H3,1.1.1���H3H:<n>.<n>.<n+> Body. ���f�@��������HU��� ������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H4,1.1.1.1���H4H:<n>.<n>.<n>.<n+> Body. ���f�@��������HU��� ������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H5,1.1.1.1.1���H5H:<n>.<n>.<n>.<n>.<n+> Body. ��� f�@���������D����������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� Note����� P1,Normal. �f�@��������LA���������� ������������������������� �� NumberedList1���� L:<n=1>)\tL,NumberedListb. �f�@��������L���������� ������������������������� �� NumberedList2���� L:<n+>)\t�. �f�@��������ZA���������� ������������������������� �� NumberedLista���� Z:<a=1>)\t NumberedList2. �f�@��������Z���������� ������������������������� �� NumberedListb���� Z:<a+>)\t�. 33�f�@��������ZA���������� ��������������������������� NumberedListi���� Z:<r=1>)\tNumberedListii. 33�f�@��������Z���������� ��������������������������� NumberedListii���� Z:<r+>)\t�. 33�f�@��������LA���������� �������������������������33�� NumberedNote1���� L:<n=1>)\tL,NumberedListb. 33�f�@��������L���������� �������������������������33�� NumberedNote2���� L:<n+>)\t�. �����f�@���������������������� ����������������������������� ���� PageFooter.left������. �����f�@���������������������� ����������������������������� ���� PageFooter.right������. ������f�@���������������������� ����������������������������� PageHeader.left������. �����f�@���������������������� ����������������������������� PageHeader.right������. ���� �@��@��������HQ������������ =������������� ����������SectionHeading����H:Section <n+> SectionTitle. ��� f�@���������T��������������������������� ���������� SectionTitle�����Body. ��� �@��@��������SA��� �������� ��������������������������SyntaxBoxCaption����S:Syntax<$chapnum><n+>Body. ��� �@��@��������SA������������ ��������������������������SyntaxBoxCaption.1����S:Syntax<$chapnum><n=1>Body. �����f�@������������������ �������������������������� TableText������. ������@��@��������TA��� ������� ���������������� ���������� TableTitle����T:Table<n=1><n+>: Body. ��� �f�@��������GE��� �������� ���������������� ����������x.Annex.FigureTitle����G:Figure <A=1><n+>T,Text. ��� �f�@��������AU����������� ���������������� ����������x.Annex.H1,A.1���� A:<A>.<n+> T,Text. ����f�@��������AE��� �������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.Annex.H2,A.1.1���AH2A:<A>.<n>.<n+> T,Text. ����f�@��������AE��� �������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.Annex.H3,A.1.1.1���AH3A:<A>.<n>.<n>.<n+> T,Text. ��� �f�@��������AE��� �������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.Annex.H4,A.1.1.1.1���AH4A:<A>.<n>.<n>.<n>.<n+> T,Text. ��� �f�@��������AE��� �������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.Annex.H5,A.1.1.1.1.1���AH5A:<A>.<n>.<n>.<n>.<n>.<n+> T,Text. �����@��@��������AQ����������� =������������� ����������x.Annex.Heading���� A:Annex <A+> SectionTitle. ����f�@������������������� ��������������������������x.Annex.normative������. �����f�@��������QE��� �������� ���������������� ����������x.Annex.TableTitle����Q:Table <A=1><n+>T,Text. ���� f�@���������T��������������������������� ���������� x.Annex.Title�����T,Text. ��� �f�@��������HE��� �������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.BNF.H2��� definition H:<n>.<n+> P1,Normal. ��� �f�@��������HE����������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.BNF.H3��� definitionH:<n>.<n>.<n+> P1,Normal. ��� �f�@��������HE����������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.BNF.H4��� definitionH:<n>.<n>.<n>.<n+> P1,Normal. ��� �f�@��������HE����������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� x.BNF.H5��� definitionH:<n>.<n>.<n>.<n>.<n+> P1,Normal. ������@��@���������������������� ���������������������������Body������. �����@��@��������������������� ��������������������������� A�� f�� ���� ���� ���� ���� ���� XCourier12������. �����f�@���������������������� ������������������������� �� 6�� Q�� l�� ���� ���� ���� ���� ���� ���� )���� D���� _���� CellBody������. �����f�@������������������� ���������������� ���������� CellHeading������. ������@��@��������T�A��� ������� ���������������� ���������� TableTitle����T:Table<n=1><n+>: Body. ������@��@��������������������� ��������������������������Mapping Table Title������. ������@��@��������������������� ���������������������������Mapping Table Title������. ������@��@��������������������� ���������������������������Mapping Table Cell������. ������@��@������������������������������������� �����������Mapping Table Cell������. ������@��@������������������������������������� ���������� �Mapping Table Cell������. ������@��@��������������������� ���������������� ����������!�Mapping Table Cell������. ��� �f�@������������������� ��������������������������Body������. �����f�@����������������������� ����������������������������� PageHeader.right������. �����f�@����������������������� ��������������������������� ���� ���� ���� PageFooter.right������. ������f�@����������������������� ����������������������������� ���� PageHeader.left������. �����f�@����������������������� ��������������������������� ���� ���� ���� PageFooter.left������. ���� �@��@��������H�Q������������ =������������� ����������SectionHeading����H:Section <n+> SectionTitle. ��� f�@��������H�U���������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H2,1.1���H2 H:<n>.<n+> Body. ��� f�@��������H�U��� ������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H3,1.1.1���H3H:<n>.<n>.<n+> Body. ��f�@���������������������� �������������������������(�� <�� P�� d�� x�� ���� ���� ���� ���� ���� ���� ���� ���� ,���� @���� T���� h���� |���� ���� ���� ���� ���� Body.Indented.1������. ���f�@��������D������������� ��������������������������� DashedList����D:\t�. ��� f�@����������D����������� ������������������������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� Note����� P1,Normal. ���f�@����������������������� ������������������������� $�� 4�� D�� T�� d�� t�� ���� ���� ���� ���� ���� ���� ���� ���� ���� ���� $���� 4���� D���� T���� d���� t���� ���� ���� ���� ���� ���� ���� ExampleCode.Indented������. ��f�@���������������������� �������������������������-(�� <�� P�� d�� x�� ���� ���� ���� ���� ���� ���� ���� ���� ,���� @���� T���� h���� |���� ���� ���� ���� ���� Body.Indented.1������. ���f�@��������H�U��� ������� ���������������� ��������� $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� H4,1.1.1.1���H4H:<n>.<n>.<n>.<n+> Body. ��� �f�@������������������� �������������������������0�Body������. � ��<f�@��������������������� ���������������� ���������4 $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� P1,Normal������. ����f�@��������������������� �������������������������5 $�� H�� l�� ���� ���� ���� ���� ���� D���� h���� ���� FL,FlushLeft������. ��� �@��@��������������������� ��������������� ����������60�� ����..SectionHeadingTOC������. ������@��@��������������������� ��������������� ����������6�� *�� ����.. H2,1.1TOC������. ��� �@��@��������������������� ��������������� ����������6�� �� ����..H1,1stLevelHeadTOC������. ������@��@��������������������� ��������������� ����������6�� -�� ����..AT,AnnexTitleTOC������. ������@��@��������������������� ��������������� ����������6-�� F�� Z�� ����.. AH2,A.1.1TOC������. ���� �@��@��������������������� ��������������� ����������6-�� F�� ����.. AH1,A.1TOC������. ��� �@��@��������������������� ��������������� ����������6-�� ����..x.Annex.HeadingTOC������. ���� �@��@��������������������� ��������������� ����������6-�� ����.. AN,AnnexTOC������. �� �������������"�������1.DELETE ������������� �������2.DRAFT1 �� =����vp��� ��������3.FIX �� =��������������������3.FIX ������������������������ ������������������������ �������3 8���� ��������� �������i_mF������������� �������VHg���� ��������� ��������������� ����������� =������������ ���������& �������[���� ��������� ������������� ������2.DRAFT2 ������������� �������2.NEW �� =���������� �������3.FIX ��������������������� BNFitalic ������������� ������� BNFkeyword ��������������������Code ������������  ������ comment_AIL ������������ � �������Keyword ������������� �������new_AIL ���������������������� Superscript ������������������������� �������i_mF������������� ���������������������������������������� ������������������������� ���������� ��������������� ���������������������������������� ��������������� ��������� �������������� ��������2.NEW �������f��� ��������� BNFitalic �������i_mF������������Code �������������� ���������� ��������������  ������� comment_AIL ��������������� ������� comment_AIL �������������� ��������new_AIL �����������������������2.NEW �������������� ��������� BNFitalic ������������������������ ��������������  ��������2.NEW ��������������� ��������2.NEW ������������������������ �������i_mF��� ��������2.NEW �������i_mF��� ��������� BNFitalic ��������������� �������� BNFkeyword ��������������� ��������� �������yc>������������� �������ڝ��� ����������� ����������������������d�����������d����������������������d�����������d�����������d�������������d����������d�������Thin����Medium����Double����Thick�@���� Very Thin�������������������� ��>�������0;<;�33=<=�33=<=�33=<=�33=<=�Format A� ����>�������H=<=�H=<=�H=<=�H=<=�H=<=�Format B���?�����������H:::� Mapping Table���z��>����/��������:::�H:::�6:::�-:::�?:::��� @��0 ��������:::���:::�H:::�z�� ����1!*������h:::�h:::�h:::�B:::�_�� N��2+0��������:::���:::�?:::�^ ��313������ev:::�ev:::�C:::�Q:::��� p��44<������H:::���:::�?:::�)�� W��5=C������l:::�u:::�H:::��C���z�� �����L������������� ���z������L������� ��� �� � ������z������L����������������z������L�������������������z��,����L�������������������z������L����������� ��!��"����z������L������#���$��%��&��'����z������ L������(���)��*��+��,����z������ L������- ���. ��/ ��0 ��1 ����z������ L������2 ���3 ��4 ��5 ��6 ����z������ L������7 ���8 ��9 ��: ��; ����z��,���� L������< ���= ��> ��? ��@ ����z������ L������A ���B ��C ��D ��E ����z������ L������F���G��H��I��J����z��,����L������K���L��M��N��O����z��,����O�����P���Q��R��S��T����z������O������U���V��W��X��Y����z������O������Z���[��\��]��^����z������O������_���`��a��b��c����z������O������d���e��f��g��h����z������O������i���j��k��l��m����z������O������n���o��p��q��r����z������O������s���t��u��v��w����z������O������x���y��z��{��|����z������O������}���~�����������z�������O�������������������� �����O����������� ���������O������� ��� �� ����������O������ ���������������O��������������������� O����������������������O������ ��� �� ����z�� �����"R�������!���!�!�!���z������!#R�������"���"��"�� "����z��,����"$R������!#���"#��##��$#����z������#%R������%$���&$��'$��($����z��,����$&R������)%���*%��+%��,%����z������%'R������-&���.&��/&��0&����z��,����&(R������1'���2'��3'��4'����z������')R������5(���6(��7(��8(����z��,����(*R������9)���:)��;)��<)����z������)�R������=*���>*��?*��@*����_�� �����,R�������A+���B+�C+���_������+-R�������D,���E,��F,����_������,.R������G-���H-��I-����_������-/R������J.���K.��L.����_������.0R������M/���N/��O/����_������/�R������P0���Q0��R0����^ �����2U�������S1���T1�U1�V1���^����13U�������W2���X2��Y2��Z2����^����2�U������[3���\3��]3��^3������ �����5U�������_4���`4�a4���������46U�������b5���c5��d5����������57U������e6���f6��g6����������68U������h7���i7��j7����������79U������k8���l8��m8����������8:U������n9���o9��p9����������9;U������q:���r:��s:����������:<U������t;���u;��v;����������;�U������w<���x<��y<����)�� �����>X�������z=���{=�|=���)������=?X�������}>���~>��>����)������>@X�������?���?��?����)������?AX������@���@��@����)������@BX������A���A��A����)������ACX������ B��� B�� B����)������B�X������ C��� C��C�����Comment�#��������� �� �� ���Μ��Ρ��&��&��l��Ψ��Ŧ� ��#$ ��&' ��() ��*+ �γ�67�m�89 �q�:; �t�<= �w�?@ ��AB ��CD��EF��GH��IJ��KL��MN��OP�T�QR�X�ST�[�UV�^������d� �Black�������T!�White����dd���A�Red���dd�����Green���d�d��� �Blue���d�����Cyan�����d���Magenta����d���� �Yellow������Header/Footer $1Header/Footer $1Header/Footer $2Header/Footer $2IndexIndexCommentCommentSubjectSubjectAuthorAuthorGlossaryGlossaryEquationEquation Hypertext Hypertext  Cross-Ref Cross-Ref Conditional TextConditional TextPositionFMPrivatePositionFMPrivateRangeEndFMPrivateRangeEndFMPrivate HTML Macro HTML Macro����� �TimesNewRomanPSMT� FrameRoman��TimesNewRomanPS-BoldMT� FrameRoman�W.Comic Sans MS.R.700�� FrameRoman�Arial-ItalicMT� FrameRoman�W.Courier New.R.400�� FrameRoman� Arial-BoldMT� FrameRoman��Helvetica-Bold� FrameRoman�� Helvetica� FrameRoman�� Times-Roman� FrameRoman�W.Courier New.R.700�� FrameRoman�TimesNewRomanPS-ItalicMT� FrameRoman�W.Courier New.I.400�� FrameRomanTimes TimesNewRoman HelveticaArial CourierNew Comic Sans MS RegularRegular BoldRegularItalic��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������� N9T F_ɔ lCn_-UQq, BӸ\&o l0hUQ7^^SN+N8[* @G0Yf]~^})'9vD’Yms#گ1$]vc:׏z&,G 1BXjЩQȍ=Yp gOz{J_ࢎo/^ǔdIp7(?;HM5UTuf(OFtrpz 75J)ژ>[\3"sIr&&WF/;{?g>0ʲkt:E9poUfo޸*|sZd@n\botRFZ\!G;Mfe0&Bf빘>ݼ@!b����