Running Emulation

The Vitis tool uses the Vivado logic simulator (xsim) as the default simulator for all platforms, including Alveo Data Center accelerator cards, and Versal and Zynq UltraScale+ MPSoC embedded platforms. However, for Versal embedded platforms, like xilinx_vck190_base or custom platforms similar to it, the Vitis tool also supports the use of third-party simulators for hardware emulation: Mentor Graphics Questa Advanced Simulator, Xcelium, and VCS. The specific versions of the supported simulators are the same as the versions supported by Vivado Design Suite.

Enabling a third-party simulator requires some additional configuration options to be implemented during generation of the device binary (.xclbin) and supporting Tcl scripts. The specific requirements for each simulator is discussed below. Also, note that you should run the Vivado setup for third-party simulators before using those simulators in Vitis. Specifically, you must pre-compile the simulation models using the compile_sim_lib Tcl command. For more details, see the Vivado Design Suite User Guide: Logic Simulation (UG900) for third-party simulator setup.

Questa

Add the following advanced parameters and Vivado properties to a configuration file for use during linking:

## Final set of additional options required for running simulation using Questa Simulator
[advanced]
param=hw_emu.simulator=QUESTA
[vivado]
prop=project.__CURRENT__.simulator.questa_install_dir=/tools/gensys/questa/2020.4/bin/
prop=project.__CURRENT__.compxlib.questa_compiled_library_dir=<install_dir>/clibs/questa/2020.4/lin64/lib/
prop=fileset.sim_1.questa.compile.sccom.cores={4}

After generating the configuration file you can use it in the v++ command line as follows:

v++ -link --config questa_sim.cfg

Xcelium

Add the following advanced parameters and Vivado properties to a configuration file for use during linking:

## Final set of additional options required for running simulation using Xcelium Simulator
[advanced]
param=hw_emu.simulator=XCELIUM
[vivado]
prop=project.__CURRENT__.simulator.xcelium_install_dir=/tools/dist/xlm/20.09.006/tools.lnx86/xcelium/bin/
prop=project.__CURRENT__.compxlib.xcelium_compiled_library_dir=/clibs/xcelium/20.09.006/lin64/lib/ 
prop=fileset.sim_1.xcelium.elaborate.xmelab.more_options={-timescale 1ns/1ps} 

After generating the configuration file you can use it in the v++ command line as follows:

v++ -link --config xcelium.cfg

VCS

Add the following advanced parameters and Vivado properties to a configuration file for use during linking:

## Final set of additional options required for running simulation using VCS Simulator
[advanced]
param=hw_emu.simulator=VCS
[vivado]
prop=project.__CURRENT__.simulator.vcs_install_dir=/tools/gensys/vcs/R-2020.12/bin/
prop=project.__CURRENT__.compxlib.vcs_compiled_library_dir=/clibs/vcs/R-2020.12/lin64/lib/
prop=project.__CURRENT__.simulator.vcs_gcc_install_dir=/tools/installs/synopsys/vg_gnu/2019.06/amd64/gcc-6.2.0_64/bin

After generating the configuration file you can use it in the v++ command line as follows:

v++ -link --config vcs_sim.cfg

You can use the -user-pre-sim-script and -user-post-sim-script options from the launch_emulator.py command to specify Tcl scripts to run before the start of simulation, or after simulation completes. As an example, in these scripts, you can use the $cwd command to get the run directory of the simulator and copy any files needed prior to simulation, or copy any output files generated at the end of simulation.

To enable hardware emulation, you must setup the environment for simulation in the Vivado Design Suite. A key step for setup is pre-compiling the RTL and SystemC models for use with the simulator. To do this, you must run the compile_sim_lib command in the Vivado tool. For more information on pre-compilation of simulation models, refer to the Vivado Design Suite User Guide: Logic Simulation (UG900).

When creating your Versal platform ready for simulation, the Vivado tool generates a simulation wrapper which must be instantiated in your simulation test bench. So, if the top most design module is <top>, then when calling launch_simulation in the Vivado tool, it will generate a <top>_sim_wrapper module, and also generates xlnoc.bd. These files are generated as simulation-only sources and will be overwritten anytime launch_simulation is called in the Vivado tool. Platform developers need to instantiate this module in the test bench and not their own <top> module.

Hardware emulation uses RTL and SystemC models for execution. A regular application and HLS-based kernel developer does not need to be aware of the hardware level details. The Vitis analyzer provides sufficient details of the hardware execution model. However, for advanced users who are familiar with HW signal and protocols, they can launch hardware emulation with the simulator waveform running, as described in Waveform View and Live Waveform Viewer.

By default, when running v++ --link -t hw_emu, the tool compiles the simulation models in optimized mode. However, when you also specify the -g switch, you enable hardware emulation models to be compiled in debug mode. During the application runtime, use the -g switch with the launch_hw_emu.sh command to run the simulator interactively in GUI mode with waveforms displayed. By default, the hardware emulation flow adds common signals of interest to the waveform window. However, you can pause the simulator to add signals of interest and resume simulation.

add_wave <HDL_objects>

Using the add_wave command, you can specify full or relative paths to HDL objects. For additional details on how to interpret the TLM waveform and how to add interfaces in the GUI, see the Vivado Design Suite User Guide: Logic Simulation (UG900).

The process for defining a SystemC model uses the following steps:

1. Include header files "xtlm_ap_ctrl.h" and "xtlm.h".
2. Derive your kernel from a predefined class based on the supported kernel types: ap_ctrl_chain, ap_ctrl_hs, etc.
3. Declare and define the AXI interfaces used on your kernel.
4. Add required kernel arguments with the correct address offset and size.
5. Write the kernel body in main() thread.

This process is demonstrated in the code example below.

When creating the SystemC model, you derive the kernel from a class-based on a supported control protocol: xtlm_ap_ctrl_chain, xtlm_ap_ctrl_hs, and xtlm_ap_ctrl_none. Use the following structure to create your SystemC model.

#include "xtlm.h"
#include "xtlm_ap_ctrl.h"
 
class vadd : public xsc::xtlm_ap_ctrl_hs
{
    public:
        SC_HAS_PROCESS(vadd);
        vadd(sc_module_name name, xsc::common_cpp::properties& _properties):
        xsc::xtlm_ap_ctrl_hs(name)
        {
            DEFINE_XTLM_AXIMM_MASTER_IF(in1, 32);
            DEFINE_XTLM_AXIMM_MASTER_IF(in2, 32);
            DEFINE_XTLM_AXIMM_MASTER_IF(out_r, 32);
 
           ADD_MEMORY_IF_ARG(in1,   0x10, 0x8);
           ADD_MEMORY_IF_ARG(in2,   0x18, 0x8);
           ADD_MEMORY_IF_ARG(out_r, 0x20, 0x8);
           ADD_SCALAR_ARG(size,     0x28, 0x4);
 
            SC_THREAD(main_thread);
        }
 
 
        //! Declare aximm interfaces..
        DECLARE_XTLM_AXIMM_MASTER_IF(in1);
        DECLARE_XTLM_AXIMM_MASTER_IF(in2);
        DECLARE_XTLM_AXIMM_MASTER_IF(out_r);
 
        //! Declare scalar args...
        unsigned int size;
 
        void main_thread()
        {
            wait(ev_ap_start); //! Wait on ap_start event...
 
            //! Copy kernel args configured by host...
            uint64_t  in1_base_addr = kernel_args[0];
            uint64_t  in2_base_addr = kernel_args[1];
            uint64_t  out_r_base_addr = kernel_args[2];
            size = kernel_args[3];
 
            unsigned data1, data2, data_r;
            for(int i = 0; i < size; i++) {
                in1->read(in1_base_addr + (i*4), (unsigned char*)&data1);  //! Read from in1 interface
                in2->read(in2_base_addr + (i*4), (unsigned char*)&data2);  //! Read from in2 interface
 
                //! Add data1 & data2 and write back result
                data_r = data1 + data2;                //! Add
                out_r->write(out_r_base_addr + (i*4), (unsigned char*)&data_r); //! Write the result
            }
 
            ap_done(); //! completed Kernel computation...
        }
 
};

The include files are available in the Vitis installation hierarchy under the $XILINX_Vivado/data/systemc/simlibs/ folder.

The kernel name is specified when defining the class for the SystemC model, as shown above, inheriting from the xtlm_ap_ctrl_hs class.

DECLARE_XTLM_AXIMM_MASTER_IF(in1);
DEFINE_XTLM_AXIMM_MASTER_IF(in1, 32);

ADD_MEMORY_IF_ARG(in1, 0x10, 0x8);

When specifying the kernel arguments, offsets, and size, these values should match the values reflected in the AXI4-Lite interface of the XRT-managed kernel as described in SW-Controllable Kernels and Control Requirements for XRT-Managed Kernels.

The addresses below 0x10 are reserved for use by XRT for managing kernel execution. Kernel arguments can be specified from 0x10 onwards. Most importantly the arguments, offsets, and size specified in the SystemC model should match the values used in the Vitis HLS or RTL kernel.

The the kernel is executed in the SystemC main_thread. This thread waits until the ap_start bit is set by the host application, or XRT, at which time the kernel can process argument values as shown:

1. The kernel waits for a signal to begin from XRT (ev_ap_start).
2. Kernel arguments are mapped to variables in the SystemC model.
3. The inputs are read.
4. The vectors are added and the result is captured.
5. The output is written back to the host.
6. The finished signal is sent to XRT (ap_done).

To generate XO file from the SystemC model, use the create_sc_xo command. This takes the SystemC kernel source file as input and creates IP that generates the XO, which can be used for linking with the target platform and other kernels with the Vitis compiler. For example:

create_sc_xo vadd.cpp 

Generating an XO file from the source file involves a number of intermediate steps like generating a Package IP script, and running the package_xo command. These intermediate commands can be used for debugging if necessary.

The output of the above create_sc_xo command is vadd.xo.

v++ --link --platform <platform> --target hw_emu \
--config ./vadd.cfg --input_files ../vadd.xo --output ../vadd.link.xclbin \
--optimize 0 --save-temps --temp_dir ./hw_emu

The SystemC model can be used for both software emulation and hardware emulation, but is not supported for hardware build targets.

When a SystemC model is included in the xclbin, the design is no longer clock cycle accurate due to the limitations of the TLM.

Xilinx devices have rich I/O interfaces. The Alveo accelerator cards primarily have PCIe and DDR memory interfaces which have their own specific model. However, your platforms could also have other I/Os, for example GT-kernel based generic I/O, Video Streams, and Sensor data. I/O Traffic Generator kernels provide a method for platforms and applications to inject traffic onto the I/O during simulation.

This solution requires both the inclusion of streaming I/O kernels (XO) or IP in your design, and the use of a Python/C++/C provided by Xilinx to inject traffic or to capture output data from the emulation process. The Xilinx provided Python/C++/C library can be used to integrate traffic generator code into your application, run it as a separate process, and have it interface with the emulation process. Currently, Xilinx provides a library that enables interfacing at AXI4-Stream level to mimic any Streaming I/O and AXI3/AXI4 memory mapped interface to mimic any memory mapped I/O.

The following section is specific to AXI4-Stream. The streaming I/O model can be used to emulate streaming traffic on the platform, and also support delay modeling. You can add streaming I/O to your application, or add them to your custom platform design as described below:

• Streaming I/O kernels can be added to the device binary (xclbin) file like any other compiled kernel object (XO) file, using the v++ --link command. The Vitis installation provides kernels for AXI4-Stream interfaces of various data widths. These can be found in the software installation at $XILINX_VITIS/data/emulation/XO.

  Add these to your designs using the following example command:

  v++ -t hw_emu --link $XILINX_VITIS/data/emulation/XO/sim_ipc_axis_master_32.xo $XILINX_VITIS/data/emulation/XO/sim_ipc_axis_slave_32.xo ... 

  In the example above, the sim_ipc_axis_master_32.xo and sim_ipc_axis_slave_32.xo provide 32-bit master and slave kernels that can be linked with the target platform and other kernels in your design to create the .xclbin file for the hardware emulation build.

• IPC modules can also be added to a platform block design using the Vivado IP integrator feature for Versal and Zynq UltraScale+ MPSoC custom platforms. The tool provides sim_ipc_axis_master_v1_0 and sim_ipc_axis_slave_v1_0 IP to add to your platform design. These can be found in the software installation at $XILINX_VIVADO/data/emulation/hw_em/ip_repo.

  The following is an example Tcl script used to add IPC IP to your platform design, which will enable you to inject data traffic into your simulation from an external process written in Python or C++:

  #Update IP Repository path if required
  set_property  ip_repo_paths $XILINX_VIVADO/data/emulation/hw_em/ip_repo [current_project]
  ## Add AXIS Master
  create_bd_cell -type ip -vlnv xilinx.com:ip:sim_ipc_axis_master:1.0 sim_ipc_axis_master_0
  #Change Model Property if required
  set_property -dict [list CONFIG.C_M00_AXIS_TDATA_WIDTH {64}] [get_bd_cells sim_ipc_axis_master_0]
  
  ##Add AXIS Slave
  create_bd_cell -type ip -vlnv xilinx.com:ip:sim_ipc_axis_slave:1.0 sim_ipc_axis_slave_0
  #Change Model Property if required
  set_property -dict [list CONFIG.C_S00_AXIS_TDATA_WIDTH {64}] [get_bd_cells sim_ipc_axis_slave_0]

You must also include a traffic generator process while simulating your application to generate data traffic on the I/O traffic generators, or to capture output data from the emulation process. The Xilinx provided Python or C++ library can be used to create the traffic generator code as described below. Also, an application can communicate to multiple I/O interface. It is not necessary to have each instance of I/O utilities to be in a separate process/thread. In case your application demands it, you might consider the non-blocking version APIs (details provided in the following section).

• For Python, set $PYTHONPATH on the command terminal:

  setenv PYTHONPATH $XILINX_VIVADO/data/emulation/hw_em/lib/python:\
  $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/python/

• Sample Python code to connect with the gt_master instance would look like the following:

  Blocking Send
  from xilinx_xtlm import ipc_axis_master_util
  from xilinx_xtlm import xtlm_ipc
  import struct
   
  import binascii
    
  #Instantiating AXI Master Utilities
  master_util = ipc_axis_master_util("gt_master")
    
  #Create payload
  payload = xtlm_ipc.axi_stream_packet()
  payload.data = "BINARY_DATA" # One way of getting "BINARY_DATA" from integer can be like payload.data = bytes(bytearray(struct.pack("i", int_number))) More info @ https://docs.python.org/3/library/struct.html
  payload.tlast = True #AXI Stream Fields
  #Optional AXI Stream Parameters
  payload.tuser = "OPTIONAL_BINARY_DATA"
  payload.tkeep = "OPTIONAL_BINARY_DATA"
    
  #Send Transaction
  master_util.b_transport(payload)
  master_util.disconnect() #Disconnect connection between Python & Emulation

• Sample Python code to connect with the gt_slave instance would look like the following:

  Blocking Receive
  from xilinx_xtlm import ipc_axis_slave_util
  from xilinx_xtlm import xtlm_ipc
    
  #Instantiating AXI Slave Utilities
  slave_util = ipc_axis_slave_util("gt_slave")
    
    
  #Sample payload (Blocking Call)
  payload = slave_util.sample_transaction()
  slave_util.disconnect() #Disconnect connection between Python & Emulation

• For non-blocking version APIs in Python, it can be found at:

  $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/python/xilinx_xtlm.py

• For C++ the APIs are available at:

  $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/cpp/inc/axis

  The C++ API provides both blocking and non-blocking function support. The following snippets show the usage.
  TIP: A sample Makefile is also available to generate the executable.
• Blocking send:
  A simple API is available if you prefer not to have fine granular control (recommended):

  #include "xtlm_ipc.h" //Include file
  void send_data() 
  {
   //! Instantiate IPC socket with name matching in IPI diagram...
   xtlm_ipc::axis_initiator_socket_util<xtlm_ipc::BLOCKING> socket_util("gt_master");
   const unsigned int NUM_TRANSACTIONS = 8;
   std::vector<char> data;
   std::cout << "Sending " << NUM_TRANSACTIONS << " data transactions..." <<std::endl;
   for(int i = 0; i < NUM_TRANSACTIONS; i++) {
   data = generate_data();
   print(data);
   socket_util.transport(data.data(), data.size());
   }
  }

  For advanced users who need fine granular control over AXI4-Stream can use the following:

  #include "xtlm_ipc.h" //Include file
   
  void send_packets()
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_initiator_socket_util<xtlm_ipc::BLOCKING> socket_util("gt_master");
   
      const unsigned int NUM_TRANSACTIONS = 8;
      xtlm_ipc::axi_stream_packet packet;
   
      std::cout << "Sending " << NUM_TRANSACTIONS << " Packets..." <<std::endl;
      for(int i = 0; i < NUM_TRANSACTIONS; i++) {
          xtlm_ipc::axi_stream_packet packet;
          // generate_data() is your custom code to generate traffic 
          std::vector<char> data = generate_data();
          //! Set packet attributes...
          packet.set_data(data.data(), data.size());
          packet.set_data_length(data.size());
          packet.set_tlast(1);
          //Additional AXIS attributes can be set if required
          socket_util.transport(packet); //Blocking transport API to send the transaction
      }
  }

• Blocking receive:
  A simple API is available if you prefer not to have fine granular control (recommended):

  #include "xtlm_ipc.h" //Include file
  void receive_data()
  {
   //! Instantiate IPC socket with name matching in IPI diagram...
   xtlm_ipc::axis_target_socket_util<xtlm_ipc::BLOCKING> socket_util("gt_slave");
   const unsigned int NUM_TRANSACTIONS = 100;
   unsigned int num_received = 0;
   std::vector<char> data;
   std::cout << "Receiving " << NUM_TRANSACTIONS << " data transactions..." <<std::endl;
   while(num_received < NUM_TRANSACTIONS) {
   socket_util.sample_transaction(data);
   print(data);
   num_received += 1;
   }
  }

  For advanced users who need fine granular control over AXI4-Stream can use the following:

  #include "xtlm_ipc.h"
   
  void receive_packets()
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_target_socket_util<xtlm_ipc::BLOCKING> socket_util("gt_slave");
   
      const unsigned int NUM_TRANSACTIONS = 8;
      unsigned int num_received = 0;
      xtlm_ipc::axi_stream_packet packet;
   
      std::cout << "Receiving " << NUM_TRANSACTIONS << " packets..." <<std::endl;
      while(num_received < NUM_TRANSACTIONS) {
          socket_util.sample_transaction(packet); //API to sample the transaction
          //Process the packet as per requirement.
          num_received += 1;
      }
  }

• Non-Blocking send:

  #include <algorithm>    // std::generate
  #include "xtlm_ipc.h"
   
  //A sample implementation of generating random data.
  xtlm_ipc::axi_stream_packet generate_packet()
  {
      xtlm_ipc::axi_stream_packet packet;
      // generate_data() is your custom code to generate traffic
      std::vector<char> data = generate_data();
   
      //! Set packet attributes...
      packet.set_data(data.data(), data.size());
      packet.set_data_length(data.size());
      packet.set_tlast(1);
      //packet.set_tlast(std::rand()%2);
      //! Option to set tuser tkeep optional attributes...
   
      return packet;
  }
   //Simple Usage
  
  void send_data() 
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_initiator_socket_util<xtlm_ipc::NON_BLOCKING> socket_util("gt_master");
  
      const unsigned int NUM_TRANSACTIONS = 8;
      std::vector<char> data;
  
      std::cout << "Sending " << NUM_TRANSACTIONS << " data transactions..." <<std::endl;
      for(int i = 0; i < NUM_TRANSACTIONS/2; i++) {
          data = generate_data();
          print(data);
          socket_util.transport(data.data(), data.size());
      }
  
      std::cout<< "Adding Barrier to complete all outstanding transactions..." << std::endl;
      socket_util.barrier_wait();
      for(int i = NUM_TRANSACTIONS/2; i < NUM_TRANSACTIONS; i++) {
          data = generate_data();
          print(data);
          socket_util.transport(data.data(), data.size());
      }
  }
  void send_packets()
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_initiator_socket_util<xtlm_ipc::NON_BLOCKING> socket_util("gt_master"); 
      // Instantiate Non Blocking specialization
   
      const unsigned int NUM_TRANSACTIONS = 8;
      xtlm_ipc::axi_stream_packet packet;
   
      std::cout << "Sending " << NUM_TRANSACTIONS << " Packets..." <<std::endl;
      for(int i = 0; i < NUM_TRANSACTIONS; i++) {
          packet = generate_packet(); // Or user's test patter / live data etc.
          socket_util.transport(packet);
      }
  }

• Non-Blocking receive:

  #include <unistd.h>
  #include "xtlm_ipc.h"
  //Simple Usage 
  void receive_data()
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_target_socket_util<xtlm_ipc::NON_BLOCKING> socket_util("gt_slave");
  
      const unsigned int NUM_TRANSACTIONS = 8;
      unsigned int num_received = 0, num_outstanding = 0;
      std::vector<char> data;
  
      std::cout << "Receiving " << NUM_TRANSACTIONS << " data transactions..." <<std::endl;
      while(num_received < NUM_TRANSACTIONS) {
          num_outstanding = socket_util.get_num_transactions();
          num_received += num_outstanding;
          
          if(num_outstanding != 0) {
              std::cout << "Outstanding data transactions = "<< num_outstanding <<std::endl;
              for(int i = 0; i < num_outstanding; i++) {
                  socket_util.sample_transaction(data);
                  print(data);
              }
          }
          usleep(100000);
      }
  }
  void receive_packets()
  {
      //! Instantiate IPC socket with name matching in IPI diagram...
      xtlm_ipc::axis_target_socket_util<xtlm_ipc::NON_BLOCKING> socket_util("gt_slave");
   
      const unsigned int NUM_TRANSACTIONS = 8;
      unsigned int num_received = 0, num_outstanding = 0;
      xtlm_ipc::axi_stream_packet packet;
   
      std::cout << "Receiving " << NUM_TRANSACTIONS << " packets..." <<std::endl;
      while(num_received < NUM_TRANSACTIONS) {
          num_outstanding = socket_util.get_num_transactions();
          num_received += num_outstanding;
           
          if(num_outstanding != 0) {
              std::cout << "Outstanding packets = "<< num_outstanding <<std::endl;
              for(int i = 0; i < num_outstanding; i++) {
                  socket_util.sample_transaction(packet);
                  print(packet);
              }
          }
          usleep(100000); //As transaction is non-blocking we would like to give some delay between consecutive samplings
      }
  }

• The following is an example Makefile for the blocking receive above:

  GCC=/usr/bin/g++
  IPC_XTLM=$(XILINX_VIVADO)/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/cpp/
  PROTO_PATH=$(XILINX_VIVADO)/data/simmodels/xsim/2021.1/lnx64/6.2.0/ext/protobuf/
  BOOST=$(XILINX_VIVADO)/tps/boost_1_64_0/
   
  SRC_FILE=b_receive.cpp
  .PHONY: run all
   
  default: all
   
  all : b_receive
   
  b_receive: $(SRC_FILE)
      $(GCC)   $(SRC_FILE) $(IPC_XTLM)/src/common/xtlm_ipc.pb.cc $(IPC_XTLM)/src/axis/*.cpp $(IPC_XTLM)/src/common/*.cpp -I$(IPC_XTLM)/inc/ -I$(PROTO_PATH)/include/ -L$(PROTO_PATH) -lprotobuf -o $@ -lpthread -I$(BOOST)/
  

• For C APIs, it can be found at:

  $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/C/inc/axis/c_axis_socket.h

  It can be linked against pre-compiled library at:

  $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/C/lib/

A full system-level example is available at https://github.com/Xilinx/Vitis_Accel_Examples/tree/master/emulation.

The AXI4 memory map external traffic has the following specifications:

• Only transaction-level granularity is supported.
• Re-ordering of transactions is not supported.
• Parallel Read, Write transactions are not supported (transactions will be serialized).
• Unaligned transactions are not supported.

The following figure shows the high-level design.

After generating an external process binary as shown above using the headers and sources available at $XILINX_VIVADO/data/emulation/ip_utils/xtlm_ipc/xtlm_ipc_v1_0/<supported_language>, you can run the emulation using the following steps:

1. Launch the Vitis hardware emulation or Vivado simulation using the standard process and wait for the simulation to start.
2. From another terminal(s), launch the external process such as Python/C++/C.