IP socket-based communication for

TCP/IP socket-based communication for SystemVerilog simulation Victor Besyakov BTA Design Services, IC Verimeter Ottawa, Ontario, Canada http://www.btadesignservices.com

ABSTRACT The communication between standalone SystemVerilog (SV) simulations or/and external applications can offer substantial benefits for the RTL development process. There are known examples where this can be useful, such as IoT and multi-chip "Plugfests", analog/mixed-signal co-simulations, and software-hardware verification, just to name a few. Traditionally, data exchange with the world outside of SV simulation space is done directly through SV Direct Programming Interface (DPI). However, this article focuses on a slightly different data transfer mechanism - TCP/IP socket data communication. The paper describes the basics of the TCP/IP socket initialization, SV data exchange methods, and data exchange protocol utilization. Also, it provides guidelines as to how to facilitate the development of communication between multiple stand-alone simulations.

SNUG 2018

Table of Contents 1. Introduction..................................................................................................................................................................................... 3 2. Socket interface and System Verilog DPI overview .................................................................................................... 3 2.1 Socket interface programming overview ..........................................................................................................3 2.2 System Verilog DPI overview ...................................................................................................................................5 3. TCP/IP and DPI integration: "TCP/IP Shunt" (Shunt) library ............................................................................... 5 3.1 Primitives (PRIM) Layer .............................................................................................................................................6 3.2 Client-server(CS) layer ................................................................................................................................................6 3.3 Handshake (HS) Layer .................................................................................................................................................7 4. Protocol handshake ..................................................................................................................................................................... 7 4.1 Protocol definition .........................................................................................................................................................8 4.2 Target /Initiator system parameters ...................................................................................................................9 4.2.1 TCP /IP ....................................................................................................................................................................9 4.2.2 Protocol properties ...........................................................................................................................................9 4.3 TCP/IP Socket Initialization......................................................................................................................................9 4.4 Write and Read Transaction elements. ............................................................................................................10 4.4.1 Write and Read Data request (Initiator) ............................................................................................10 4.4.2 Write and Read data acknowledge (Target). ....................................................................................11 4.4.3 Write/Read data payload ...........................................................................................................................11 5. Conclusions ................................................................................................................................................................................... 12 6. Acknowledgments ..................................................................................................................................................................... 12 7. References ..................................................................................................................................................................................... 12 1. Appendix Shunt Data type mapping ............................................................................................................................... 14 2. Appendix

“TCP/IP SHUNT “ API select features................................................................................................... 16

2.1 shunt_dpi_initiator_init ............................................................................................................................................16 2.2 shunt_dpi_target_init .................................................................................................................................................16 2.3 cs_header_t ......................................................................................................................................................................16 2.4 shunt_dpi_send_header ............................................................................................................................................16 2.5 shunt_dpi_recv_header .............................................................................................................................................16 2.6 SHUNT_INSTR_ENUM................................................................................................................................................16 2.7 shunt_dpi_hash .............................................................................................................................................................17 2.8 shunt_dpi_send_byte..................................................................................................................................................17 2.9 shunt_dpi_recv_byte...................................................................................................................................................17 2.10 shunt_dpi_send_intV ...............................................................................................................................................18

Page 2

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

2.11 shunt_dpi_recv_intV ................................................................................................................................................18 2.12 shunt_dpi_hs_send_byte ........................................................................................................................................18 2.13 shunt_dpi_hs_recv_byte .........................................................................................................................................18

Table of Figures Figure 1 Shunt directory structure ...........................................................................................................................................5 Figure 2. The Shunt Abstraction Hierarchy..........................................................................................................................6 Figure 3 PRIM layer SV->C->(TCP/IP)->C->SV flow example ...................................................................................6 Figure 4 SC layer SV->C->(TCP/IP)->C->SV flow example...........................................................................................7 Figure 5 HS layer SV->C->(TCP/IP)->C->SV Dynamic array handshake flow example ................................7 Figure 6 Simulations with shared memory ..........................................................................................................................8 Figure 7 Write request format ....................................................................................................................................................8 Figure 8 Write acknowledge format ........................................................................................................................................8 Figure 9 Read request format......................................................................................................................................................8 Figure 10 Read response format ...............................................................................................................................................8 Figure 11 Example: Initialization, Write and Read data flow .....................................................................................9

Table of Tables Table 1. 1 SV to C data type........................................................................................................................................................14

1. Introduction An idea to establish communication with RTL simulations by using TCP has been around for nearly as long as Verilog [5][7]. Many applications would benefit from this approach including multi-chip, analog/mixed-signal co-simulations, and software-hardware verification [5][6][7][8][9] [10]. There are many conference papers published on those topics. However, just a few basic TCP/IP SV DPI code examples and almost no tutorials are available on the internet [11][12]. Somehow socket interface for RTL simulation still only exists as a proprietary application-specific solution. This article and corresponding open source “TCP/IP Shunt” library [2] aim to fill this gap and address the following areas:  An overview of Socket interface and DPI,  Socket interface and DPI integration,  Handshake protocol examples.

2. Socket interface and System Verilog DPI overview 2.1 Socket interface programming overview The Network socket interface can be specified as a typical "Server-Client Connection Oriented"

Page 3

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

protocol. The "Server-client" portion of the definition implies that there are two groups of at least two participants. The first party is a "Central Resource Sever" or "Initiator" (TLM2.0[4]). The second one is a "Resident Client" or "Target" (TLM2.0[4]). The typical system consists of one Initiator and one or more Targets. To uniquely identify a data exchange session, both Initiator and Target use a combination of an IP address and a port number as a connection ID tag aka “Socket”. The "connectionoriented protocol" portion of the interface definition implies that the Initiator and the Target need “to establish an end-to-end connection before any data is sent”[14]. The following example demonstrates the basic concepts of the socket programming. Each step of the simplified data exchange flow is illustrated with corresponding Sockets library functions (see [15][16] and [17] for more detailed descriptions):  Initiator: 1. Create a socket and assign a designated TCP/IP port to the socket socket ( AF_INET, //AF_INET - use address family SOCK_STREAM, // SOCK_STREAM – socket type set to the TCP protocol 0 //0 – Default protocol specified for socket type ); 2. Build the initiator's Internet address bzero((char *) &initiatoraddr, sizeof(initiatoraddr));  build the initiator's Internet address initiatoraddr.sin_family = AF_INET;  get IP address from host initiatoraddr.sin_addr.s_addr = htonl(INADDR_ANY);  get port initiatoraddr.sin_port = htons((unsigned short)portno); 3. Bind a socket with IP address and port bind (parentfd, (struct sockaddr *) &initiatoraddr, sizeof(initiatoraddr)) 4. Set a socket to listen for incoming connection attempts from Target. listen (parentfd, 5) // allow 5 target requests to queue up targetlen = sizeof(targetaddr); target = accept(parentfd, (struct sockaddr *) &targetaddr, (socklen_t *)&targetlen); //if target > 0 request is accepted  Target: 5. Create a socket and assign initiator’s Internet address and port sockfd = socket(AF_INET, SOCK_STREAM, 0); initiator = gethostbyname(hostname); //get the initiator's DNS entry 6. Build the initiator's Internet address initiatoraddr.sin_family = AF_INET; initiatoraddr.sin_port = htons(portno); 7. Create a connection with the initiator Initiator = connect (sockfd, (struct sockaddr *)&initiatoraddr, sizeof(initiatoraddr) //if Initiator > 0 connection is established  Initiator-Target: 8. Data exchange numbytes = send(sockfd,data, sizeof(data), 0);

Page 4

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

9.

numbytes = recv(sockfd,data,sizeof(data) , 0); Close the connection close(sockfd)

2.2 System Verilog DPI overview The SystemVerilog Direct Programming Interface (DPI) “allows direct inter-language function calls between SystemVerilog and any foreign programming language with a C function call protocol and linking model”[1]. The DPI portion of the SV standard ensures uniformity between all RTL simulators (reference to Annex H and Annex I [1]). In the context of the TCP/IP inter-process communication, the most important part of the standard is how C and SV data types are mapped to each other. See Appendix 1 (Table 1. 1 SV to C data type) for more details.

3. TCP/IP and DPI integration: "TCP/IP Shunt" (Shunt) library The Shunt is an Open Source Client/Server TCP/IP communication library for SystemVerilog simulation. It aims to enable the quick and easy development of the inter-simulation communication. It provides a common SystemVerilog/C API and supports all SystemVerilog data types (see Appendix 1. ). The following diagram and notes illustrate the Shunt directory structure:

Figure 1 Shunt directory structure

   

Page 5

The “utils” directory contains C functions (reference to utils/c) and corresponding SV DPI wrappers (reference to utils/dpi) The “doc” directory – Shunt Library documentation The “bin” directory – C domain compiles results The “examples” directory contains “SV to SV” communication examples and “C to C” tests

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

The Shunt is comprised of 3 layers of abstraction: primitive (PRIM), client-server (SC), and handshake API (HS). Each layer is self-sufficient. Users can build an application from any layer of this abstraction:

Figure 2. The Shunt Abstraction Hierarchy

3.1 Primitives (PRIM) Layer The PRIM layer contains basic TCP/IP socket initialization, some generic functions, and the SV-to-C elementary data exchange. Its main purpose is to enable basic data communication. The layer contains methods to send and receive integers and IEEE 754 SV singular variable [1] data types (reference to Table 1. 1 SV to C data type). The PRIM operation doesn’t require any memory allocation. The Initiator-Target PRIM layer single byte transfer example for the SV->C->(TCP/IP)->C>SV flow is shown below:

Figure 3 PRIM layer SV->C->(TCP/IP)->C->SV flow example

3.2 Client-server(CS) layer The CS layer offers data transfers for integers, IEEE 754 SV one-dimensional arrays, and vectors. Also, it contains transaction header structures and methods that can be used to build up a client-server handshake protocol. The user application is responsible for the proper memory garbage collection. The Initiator-Target CS layer int array transfer example for the SV->C->(TCP/IP)->C->SV flow is shown below:

Page 6

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

Figure 4 SC layer SV->C->(TCP/IP)->C->SV flow example

3.3 Handshake (HS) Layer The C domain of the HS layer is a simple SV to C handshake interface. One could see it as an SC layer simplification or wrapper around SC layer. The HS layer SystemVerilog domain provides transaction data structures and functions that send and receive dynamic one-dimensional dynamic arrays (reference to Figure 5 HS layer SV->C->(TCP/IP)->C->SV Dynamic array handshake flow example ). HS layer methods can be applied both for simple and for more complex packet communication handshakes. Users can use the predefined header-data load or define their own transaction structure. The user application is responsible for the proper memory garbage collection.

Figure 5 HS layer SV->C->(TCP/IP)->C->SV Dynamic array handshake flow example

4. Protocol handshake The Shunt provides a set of functions and data structures that can be used to facilitate user-defined inter-simulation handshake development. The following example explains the application of the Shunt library methods to the hypothetical inter-simulation data exchange protocol.

Page 7

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

4.1 Protocol definition

Figure 6 Simulations with shared memory

Assume that two simulation instances need to talk to each other. The Target simulation has shared memory segment which both simulations can get access to (Figure 6 Simulations with shared memory). Let’s define the shared memory handshake as a fixed field packet-oriented protocol. The handshake packet formats are presented below:

Figure 7 Write request format

Figure 8 Write acknowledge format

Figure 9 Read request format

Figure 10 Read response format

A data handshake consists of the packet header and data payload. The packet data payload size is fixed to 4 bytes. The packet header stores the following attributes:  Transaction types: read data (READ_REQ), write data (WRITE_REQ), read acknowledge (READ_ACK), and write acknowledge (WRITE_ACK)  Transaction address: Address is 8 bits. A shared memory handshake has three components: “TCP/IP socket initialization”, followed by a series of “Write transactions” and/or “Read transaction” (see Figure 11 Example: Initialization, Write

Page 8

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

and Read data flow). The socket initialization enables TCP/IP functionality in stages. The Initiator starts first. Then the Target simulation connects to the Initiator (see section 2.1 ). For a Write transaction, the initiator starts a write handshake with a write request (see Figure 7 Write request format). Then, it waits for the write acknowledge. The Target sends WRITE ACK with ACK_OK or ACK_NOT_READY status back to the Initiator (see Figure 8 Write acknowledge format). For a Read Transaction, the Initiator polls the Target simulation by sending a Read request (see Figure 9 Read request format). If the Target response shows that data is ready, the Initiator waits for the Target to complete a transaction with READ ACK (see Figure 10 Read response format). The Target response can be ACK_OK or ACK_NOT_READY. A simplified operation flow is shown below:

Figure 11 Example: Initialization, Write and Read data flow

4.2 Target /Initiator system parameters The Initiator and the Target must know prior to the simulation a designated TCP host address and port. Also, predefined protocol properties need to be communicated to both sites. 4.2.1 TCP /IP `define MY_HOST "localhost" `define MY_PORT 3450 4.2.2 Protocol properties typedef enum{MY_WRITE, MY_READ, MY_ADDR, MY_ACK_OK, MY_ACK_NOT_READY } transaction_type_e;

4.3 TCP/IP Socket Initialization As mentioned above, the Initiator creates a socket, assigns a designated TCP/IP port to it and waits for Target connect request (see Appendix 2.1 ): socket_id = shunt_dpi_initiator_init(`MY_PORT);

Page 9

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

The Target creates a socket, assigns an Initiator’s Internet address-port pair, and creates a connection with the initiator (see Appendix 2.2 ): socket_id = shunt_dpi_target_init(`MY_PORT,` MY_HOST);

4.4 Write and Read Transaction elements. 4.4.1 Write and Read Data request (Initiator) The Shunt library has predefined header structure (cs_header_t) and corresponding send/receive methods that can be applied to produce a protocol request-acknowledge pair (see Appendix 2.3 - 2.5 ): typedef struct { real trnx_type; real trnx_id; real data_type; int n_payloads; } cs_header_t; shunt_dpi_send_header(socket_id, input cs_header_t h ); shunt_dpi_recv_header(socket_id, output cs_header_t h ); The first header data structure field (cs_header_t.trnx_type) is reserved for a user defined transaction attribute. It is possible to cast transaction_type_e enumeration type directly to a trnx_type structure element:  Write request: write_data_req.trnx_type = cs_header_t'(MY_WRITE);  Read request: read_data_req.trnx_type = cs_header_t'(MY_READ); Nevertheless, for consistency with the predefined built-in Shunt data_type, the trnx_type sets to hash index as shown below: transaction_type = MY_WRITE; write_data_req.trnx_type = shunt_dpi_hash (transaction_type.name ()); The shunt_dpi_hash is a simple djb2 hash function (see [18] and Appendix 2.7 ). The rest of the structure fields for both READ and WRITE are set as:  The trnx_id is set to user defined unique transaction number write_data_req.trnx_id = $urandom;  The data_type should be equal to hash index of the predefined Shunt enumeration type SHUNT_INSTR_ENUM (see Appendix 2.6 ): write_data_req.data_type = shunt_dpi_hash (“SHUNT_BYTE”);// by protocol definition  n_payloads is equal to 4 (4-bytes) by protocol definition. The request format consists of two fields: shunt header and address (reference to Figure 7 Write request format and Figure 10 Read response format). The Initiator sends ADDR immediately after the “Transaction type” protocol field. The protocol field ADDR doesn't require a special data structure. It can be defined as a SV byte. The Initiator-Target send-get request pair is shown below:

Page 10

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

 

Initiator (see Appendix 2.4 , 2.8 ): shunt_dpi_send_header(socket_id,data_req);) shunt_dpi_send_byte (socket_id,ADDR); Target(see Appendix 2.5 ,2.9 ): shunt_dpi_recv_header (socket_id,data_req);) shunt_dpi_recv_byte (socket_id,ADDR);

4.4.2 Write and Read data acknowledge (Target). The Shunt header structure (cs_header_t) is applied to create the Target WRITE and READ acknowledges too. In the case of acknowledgments, the trnx_type header element obtains ACK response type. According to the protocol definition, it can be equal to MY_ACK_OK or MY_ACK_NOT_READY (see Figure 8 Write acknowledge format and Figure 10 Read response format). Since the WRITE acknowledge has no data payload, the data_type is equal to SHUNT_HEADER_ONLY. The transaction ID field trnx_id is equal to the corresponding Initiator's transaction request ID. The n_payloads field has no functional meaning for WRITEs, but for the READ response, data_type is a “SHUNT_BYTE and the n_payloads is equal to payload size returned. The Target-Initiator send-get operation is shown below:  Target: shunt_dpi_send_header(socket_id,ack);  Initiator: shunt_dpi_recv_header (socket_id,ack); 4.4.3 Write/Read data payload For demonstration purposes, HS layer dynamic array methods are used to send and receive writeread data payload. As it has been shown above (Figure 5 HS layer SV->C->(TCP/IP)->C->SV Dynamic array handshake flow example ) the HS data transfer consists of following steps:  Sender: 1. prepare data to send byte ByteArray[]; ByteArray = new[n_payloads]; //memory allocation 2. set up cs_header_t fields trnx_type, trnx_id, data_type and n_payloads 3. send header to Receiver : shunt_dpi_send_header(socket_id, data_payload_header); 4. send data payload ( see Appendix 2.12 ) : shunt_dpi_hs_send_byte(sockid, payload_header,ByteArray) ;  Receiver: 1. get data payload header: shunt_dpi_recv_header(socket_id,data_payload_header); 2. allocate data payload memory : ByteArray = new[data_payload_header.n_payloads]; 3. get data payload (see Appendix 2.13 ): shunt_dpi_hs_recv_byte(socket_id,data_ack,ByteArray);

Page 11

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

5. Conclusions In this paper, a socket based open source communication library named “TCP/IP Shunt” was presented. The Shunt enables the building of high-level abstraction applications and libraries using the underlying socket protocol. It aims to minimize the up-front investment in time and effort by providing a simple, consistent API. The TCP/IP Shunt library is available under a MIT License (for more details, see[19]). It can be used without restriction in an open-source or commercial application. “TCP/IP Shunt” can be found on GitHub (https://github.com/xver/Shunt). It contains source code, numerous examples, and a full API specification.

6. Acknowledgments Special thanks to Mr. Bryan Morris for his in-depth review, numerous suggestions and remarks. And also special thanks to Mr. Igor Melamed for his invaluable feedback during the development of this paper.

7. References [1] 1800-2012 - IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language [2] SystemVerilog DPI "TCP/IP Shunt" (TCP/IP system verilog socket library) https://github.com/xver/Shunt [3] "TCP/IP Shunt API specification” https://rawgit.com/xver/Shunt/master/doc/index.html [4] IEEE Standard for Standard SystemC Language Reference Manual (Revision of IEEE Std 1666-2011) [5] D. Becker, R.K. Singh, and S.G. Tell, “An Engineering Environment for Hardware Software CO-Simulation,” DAC 1992 [6] H.Hübert “A Survey of HW/SW Cosimulation Techniques and Tools” TRITA-ESD-1998-07 ISSN 1104-8697 ISRN KTH/ESD/R--98/7--SE [7] H.P. Wen, C.Y. Lin, and Y.L. Lin, "Concurrent-Simulation-Based Remote IP Evaluation over the Internet for System-on-a-Chip Design", in Proc. 14th International Symposium on Systems Synthesis (ISSS), 1-3 October 2001, Montreal, P.Q., Canada, pp. 233-238. [8] D. Rich. “Easy Steps Towards Virtual Prototyping using the SystemVerilog DPI” Mentor Graphics DVCon 2013 [9] S.Bhattacharyya, R. Chaturvedi, B. Singh, N. Goel “QEMU based Co-simulation platform – Benefits” www.design-reuse.com/articles/42213/qemu-based-co-simulation-platform-benefits.html [10] A. Fiergolski “Simulation environment based on the Universal Verification Methodology”2017 JINST 12 C0100 [11] “A simple https://github.com/witchard/sock.sv

TCP

socket

library

for

system

Verilog”

[12] C. Spear. “Sockets, SystemVerilog Page SystemVerilog for Verification, third edition“http://spearzone.com/mb/systemverilog/examples/sockets_dpi.tar [13]

C. Spear. SystemVerilog for Verification. Springer, New York, 2nd edition, 2010

[14] “What is connection-oriented? Definition http://searchnetworking.techtarget.com/definition/connection-oriented

from

WhatIs.com”

[15] “The GNU C Library , Sockets” ftp://ftp.gnu.org/old-gnu/Manuals/glibc2.2.3/html_chapter/libc_16.html#SEC300

Page 12

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018 [16]

“Berkeley sockets” https://en.wikipedia.org/wiki/Berkeley_sockets

[17]

“Beej's Guide to Unix Interprocess Communication” https://beej.us/guide/bgipc/

[18]

O.Yigit “Hash Functions” http://www.cse.yorku.ca/~oz/hash.html

[19]

“MIT License” https://choosealicense.com/licenses/mit/

Page 13

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

1. Appendix Shunt Data type mapping The following table presents a direct SV type mapping from SV to C. It's based on System Verilog standard Table H.1 [1]and Table 12-1 from [13] : Table 1. 1 SV to C data type

SystemVeriog type

Definition

In/out C mapping data type

shortint

2-state data type,16-bit signed integer

short int/short int*

int

2-state data type,32-bit signed integer

int/int*

longint

2-state data type,64-bit signed integer

long long int/long int*

byte

2-state data type, 8-bit signed integer or ASCII character char/char*

integer

4-state data type,32-bit signed integer

int/int*

time

4-state data type, 64-bit unsigned integer

long long int/long int*

bit

2-state data type,user-defined vector size, svBit or unsigned char /svBit* unsigned or unsigned char*

reg/logic

4-state data type,user-defined vector size, svLogic or unsigned char/ unsigned svLogic* or unsigned char*

integer

Vector type bit[N:0]

2-state data type,user-defined vector size, const unsigned svBitVecVal*

reg[N:0] or logic[N:0]

4-state data type,user-defined vector size, const svLogicVecVal*/ unsigned svLogicVecVal*

Non integer IEEE 754

svBitVecVal*/

type

shortreal

data type is the same C float 4 byte

float/float*

real

data type is the same as a C double 8 byte

double/double*

realtime

same as real 8 bytes

double/double*

string

string is an ordered collection of characters indexed as an unpacked array of bytes

const char*/char**

string[N]

string is an ordered collection of characters indexed as an unpacked array of bytes

const char**/char**

A dynamic array is an unpacked array

const

special types

Arrays dynamic arrays

Page 14

svOpenArrayHandle/

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

whose size can be set or changed at run time

Page 15

svOpenArrayHandle

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

2. Appendix

“TCP/IP SHUNT “ API select features

2.1 shunt_dpi_initiator_init function int shunt_dpi_initiator_init (input int portno) TCP/IP initiator initialization  Parameters: portno - socket port  Returns: socket id (see shunt_prim_init_initiator)

2.2 shunt_dpi_target_init function int shunt_dpi_target_init (input int portno, input string hostname) TCP/IP target initialization  portno - socket port  hostname –initiator host name.

2.3 cs_header_t typedef struct cs_header_t { double trnx_type; double trnx_id; double data_type; int n_payloads; } cs_header_t  trnx_type is a user defined transaction attribute  trnx_id is a user defined unique transaction number  data_type see SHUNT_INSTR_ENUM  n_payloads is number of data payloads

2.4 shunt_dpi_send_header function int shunt_dpi_send_header(input int sockid, input cs_header_t h) Send SHUNT header over TCP/IP  Parameters : sockid - socket id from init initiator/target, h - cs_header verilog structure cs_header_t  Returns: success > 0

2.5 shunt_dpi_recv_header function int shunt_dpi_recv_header(input int sockid, output cs_header_t h) Fetch SHUNT transaction header from TCP/IP socket  Parameters: sockid - socket id from init initiator/target h - cs_header verilog structure cs_header_t  Returns: success > 0

2.6 SHUNT_INSTR_ENUM

typedef enum { SHUNT_INT SHUNT_REAL, SHUNT_SHORTREAL,

Page 16

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018

SHUNT_STRING, SHUNT_A_STRUCTURE, SHUNT_INTEGER, SHUNT_BYTE, SHUNT_REG, SHUNT_BIT, SHUNT_SHORTINT, SHUNT_LONGINT, SHUNT_HEADER_ONLY } SHUNT_INSTR_ENUM  Integer 2 states: o SHUNT_INT- SV type int o SHUNT_SHORTINT- SV type shortint o SHUNT_LONGINT- SV type longint o SHUNT_BYTE- SV type byte o SHUNT_BIT- SV type bit  Integer 4 states: o SHUNT_INTEGER- SV type integer, time o SHUNT_REG- SV type reg, logic  Non integer types IEEE 754: o SHUNT_REAL- SV type real, realtime o SHUNT_SHORTREAL - SV type shortreal  Special o SHUNT_STRING- SV type string o SHUNT_A_STRUCTURE - complex data types/user defined data types: arrays/struct,union,enums o SHUNT_HEADER_ONLY- Shunt type cs_header_t header only.

2.7 shunt_dpi_hash

function real shunt_dpi_hash(input string str) Simple hash function  Parameters: str - hash key string  Returns: hash value

2.8 shunt_dpi_send_byte

function int shunt_dpi_send_byte (input int sockid, input byte Byte) Send byte 2-state data type, 8-bit signed integer or ASCII character LRM 6.11 Integer data types char/char*  Parameters: sockid - socket id, Byte –byte data  Returns: number of bytes have been sent: success > 0

2.9 shunt_dpi_recv_byte function int shunt_dpi_recv_byte (input int sockid, output byte Byte) Receive byte 2-state data type, 8-bit signed integer or ASCII character LRM 6.11 Integer data types char/char*  Parameters: sockid- socket id, Byte – byte data

Page 17

TCP/IP socket-based communication for SystemVerilog simulation

SNUG 2018



Returns: number of bytes have been receive: success > 0

2.10 shunt_dpi_send_intV function int shunt_dpi_send_intV ( input int sockid, input int size, input int Int[] ) send unpacked "int" one-dimensional array LRM 7.4.2  Parameters: sockid- socket id, size - number of array elements,int[]- data array  Returns: success > 0

2.11 shunt_dpi_recv_intV

function int shunt_dpi_recv_intV ( input int sockid, input int size, input int Int[] )

receive unpacked "int" one-dimensional array LRM 7.4.2  Parameters: sockid- socket id, size - number of array elements,int[]- data array  Returns: success > 0

2.12 shunt_dpi_hs_send_byte function int shunt_dpi_hs_send_byte (input int sockid, input cs_header_t h_trnx, input byte Array[]) Send unpacked dynamic "byte" one-dimensional array LRM 6.11 Integer data types char/char*  Parameters: sockid - socket id, h_trnx - structure cs_header_t, Array - data  Returns: success > 0

2.13 shunt_dpi_hs_recv_byte function int shunt_dpi_hs_recv_byte (input int sockid, input cs_header_t h_trnx, out byte Array[]) Receive unpacked dynamic "byte" one-dimensional array LRM 6.11 Integer data types char/char*  Parameters: sockid - socket id, h_trnx - structure cs_header_t, Array - data  Returns: success > 0

Page 18

TCP/IP socket-based communication for SystemVerilog simulation