__ _    ____  ___     ___   _  __ ____   _____ __                               _    __________ 
       / /| |  / /  |/  /    /   | | |/ //  _/  / ___// /_________  ____ _____ ___     | |  / /  _/ __ \
      / / | | / / /|_/ /    / /| | |   / / /    \__ \/ __/ ___/ _ \/ __ `/ __ `__ \    | | / // // /_/ /
     / /__| |/ / /  / /    / ___ |/   |_/ /    ___/ / /_/ /  /  __/ /_/ / / / / / /    | |/ // // ____/ 
    /_____/___/_/  /_/    /_/  |_/_/|_/___/   /____/\__/_/   \___/\__,_/_/ /_/ /_/     |___/___/_/      
    
    

- Sending stimulus API
    - add_data
        - user can use this API to queue up the data bytes to be sent
        - can call multiple times, for example:
            <env>.add_data(.data(8'h11), .user(4'h1)); // <-- this is LSB
            <env>.add_data(.data(8'h22), .user(4'h2)); // <-- this is MSB

    - add_pos
        - user can use this API to queue up the position bytes to be sent
        - can call multiple times, for example:
            m_axis_env.add_pos (.data(8'hFF)); // <-- this is LSB
            m_axis_env.add_pos (.data(8'hEE)); // <-- this is MSB

            - note: "user" argument is omitted, thus, it will be randomized

    - add_null
        - user can use this API to queue up the null bytes to be sent
        - can call multiple times, for example:
            m_axis_env.add_null(            ); // <-- this is LSB
            m_axis_env.add_null(            ); // <-- this is MSB

            - note: "data" & "user" arguments are omitted, thus, they will be randomized

    - send
        - This api has 2 modes
            - [User defined data way]
                - User can define exact position / data / null byte to be sent by using ~add_data~ / ~add_pos~ / ~add_null~ API
                - Example below for a 64 bits bus, sending 8 bytes of data, where associated tuser is 4 bits per byte
                    <env>.add_data(.data(8'h11), .user(4'h1));
                    <env>.add_data(.data(8'h22), .user(4'h2));
                    <env>.add_data(.data(8'h33), .user(4'h3));
                    <env>.add_data(.data(8'h44), .user(4'h4));
                    <env>.add_data(.data(8'h55), .user(4'h5));
                    <env>.add_data(.data(8'h66), .user(4'h6));
                    <env>.add_data(.data(8'h77), .user(4'h7));
                    <env>.add_data(.data(8'h88), .user(4'h8));

                    <env>.send(.TID(8'hAA), .TDEST(8'hBB), .TLAST(1'b1));

                - TID=8'hAA  TDEST=8'hBB  TDATA=64'h88776655_44332211  TUSER=32'h87654321
                    - as TLAST == 1, VIP will send this packet with last beat TLAST = 1'b1

                - if user wants to specify the data with bigger width, add_data API supports "num" argument, for example,
                    <env>.add_data(.data(64'h88776655_44332211), .user(32'h8765_4321), .num(8));
                    <env>.send(.TID(8'hAA), .TDEST(8'hBB), .TLAST(1'b1));

                - Note: "data" argument supports up to 1024 bits of data


            - [Random packet]
                - User can define the packet type to be sent, and randomize the pos / data / null if applicable.
                - no need to call add_data / add_pos / add_null
                - Arguments
                    - ~beats~
                        - decide how many beats for this packet, if not specified, it will be from 1 to <env>.cfg.max_beats

                    - ~packet~
                        - decide which packet format to be sent, eg
                            - BYTE_STREAM
                            - CONT_ALIGN_STREAM
                            - CONT_UNALIGNED_DP_STREAM
                                - This is continuous unaligned stream with DATA bytes followed by POSITION bytes
                            - CONT_UNALIGNED_PD_STREAM
                                - This is continuous unaligned stream with POS  bytes followed by DATA     bytes
                            - CONT_UNALIGNED_PDP_STREAM
                                - This is continuous unaligned stream with POS  bytes followed by DATA     bytes then POS bytes again
                            - SPARSE_STREAM
                            - TLAST_STREAM
                                - Single beat of null bytes with TLAST == 1'b1
                    
                    - ~data_start_index~
                        - decides when the data bytes start in a packet.
                        - only applicable for CONT_UNALIGNED_PD_STREAM & CONT_UNALIGNED_PDP_STREAM

                    - ~data_end_index~
                        - decides when the data bytes end in a packet.
                        - only applicable for CONT_UNALIGNED_DP_STREAM & CONT_UNALIGNED_PDP_STREAM
                        
                        Note: 
                        - These 2 variables are only applicable for continuous unaligned packet only
                        - Example usage:
                            <env>.send(.TID(8'h11), .TDEST(8'h22), .TLAST(1'b1), .packet(CONT_UNALIGNED_DP_STREAM  ),                        .data_end_index  (10));
                                Index 0  to 10  = Data     Bytes
                                Index 11 to end = Position Bytes

                            <env>.send(.TID(8'h33), .TDEST(8'h44), .TLAST(1'b1), .packet(CONT_UNALIGNED_PD_STREAM  ), .data_start_index(20)                       );
                                Index 0  to 19  = Position Bytes
                                Index 20 to end = Data     Bytes

                            <env>.send(.TID(8'h55), .TDEST(8'h66), .TLAST(1'b1), .packet(CONT_UNALIGNED_PDP_STREAM ), .data_start_index(15), .data_end_index  (25));
                                Index 0  to 14  = Position Bytes
                                Index 15 to 25  = Data     Bytes
                                Index 25 to end = Position Bytes


                - Example:
                    - m_axis_env.send(.TID(8'hAA), .TDEST(8'hBB), .TLAST(1'b1), .packet(CONT_ALIGN_STREAM         ), .beats(10));
                    - This will send random data bytes for 10 clocks, with 10th clock having TLAST=1'b1


- Other generic APIs
    - <env>.cfg.posedge_clk(<number of clocks>);
        this API wait for next posedge of clock

    - <env>.cfg.negedge_clk(<number of clocks>);
        this API wait for next negedge of clock

    - 


- Configuration
    - Parameterized signal widths.
        - The list of parameters
            - TDATA_WIDTH
            - TID_WIDTH
            - TDEST_WIDTH
            - TUSER_WIDTH
            - TDATACHK_WIDTH
            - TSTRBCHK_WIDTH
            - TKEEPCHK_WIDTH
            - TIDCHK_WIDTH
            - TDESTCHK_WIDTH
            - TUSERCHK_WIDTH


    - AXI Stream VIP configurations
        - <env>.cfg.Wakeup_Signal        = LVM_TRUE  (default)
            - TWAKEUP signal is applicable when it is LVM_TRUE.

        - [TODO] <env>.cfg.protocol = LVM_AXI5_STREAM

        - For Driver
            - <env>.cfg.drv_wait_tlast = LVM_FALSE
                - LVM_TRUE , driver will wait for the tlast is sent before proceeding to next packet.
                - LVM_FALSE, all the packets will be queued.
                    - This setting allow the interleaving of driver

            - <env>.cfg.Continuous_Packets = LVM_FALSE (default)
                - if it is LVM_TRUE, VIP cannot send pos or null bytes

            - <env>.cfg.max_beats = 100
                - this limit the total T for a randomized packet.

            - <env>.cfg.total_interleaving = 5
                - total interleaving thread that can be accepted by receiver
                - once programmed, any on-going packets with TID-TDEST pairs will be interleaving, with maximum 5 sets only.
                    - the rest of the pairs will need to wait for the TLAST sent in the currently inteleaving packets.

            - <env>.cfg.tuser_style
                - User can configure the VIP based on the usage of TUSER signal.
                    - LVM_AXIS_TUSER_PER_BYTE
                        - tuser is a per byte information
                    - LVM_AXIS_TUSER_PER_TRANSFER
                        - tuser is a per transfer (1 clock of TVALID & TREADY)
                - Note: 
                    - per packet and per frame does not have any effect.


            - <env>.cfg.tdata_gap_percent
                - the percentage of having a gap of TVALID == 0 during packet sending
                - can be programmed from 0 to 100



        - For VIP Slave only
            - <env>.cfg.ever_ready = random;
                - if 1, slave will keep asserting TREADY, else it will be low for some TVALID.

            - <env>.cfg.not_ready_clks_max = 5; // Only valid when ever_ready is 0
            - <env>.cfg.not_ready_clks_min = 3; // Only valid when ever_ready is 0
                - When the setting above take effect, slave will deassert TREADY from 3 to 5 clocks.

            - <env>.cfg.not_ready_clks = 5; // Only valid when ever_ready is 0 && not_ready_clks_max and not_ready_clks_min are not configured
                - When set to 5, slave will be mostly deasserting TREADY for 5 clocks, and maybe will randomize low time from 1 to 5.

            - <env>.cfg.auto_reply = 1;
                - Slave will auto reply TREADY


        - For VIP Checker
            - <env>.cfg.max_wait_tready  = 10000    (default)
            - <env>.cfg.wait_tready_unit = "ns"     (default)
                - TVALID == 1 && TREADY == 0 wait limit in number of clocks or ns
                - if exceeded, a fatal error will be flagged

        - Optional signals
            - if TREADY is not implemented
                - DUT=master, VIP=slave: 
                    set <slave env>.cfg.ever_ready = 1

                - VIP=master, DUT=slave
                    supply 1'b1 to TREADY signal in the interface

            - if TKEEP is not implemented
                - DUT=master, VIP=slave: 
                    supply all 1's to TKEEP in the interface

                - VIP=master, DUT=slave
                    VIP can only send out data bytes or position bytes
                
            - if TSTRB is not implemented, but implemented TKEEP
                - DUT=master, VIP=slave: 
                    Supply TKEEP value to TSTRB in the interface
                
                - VIP=master, DUT=slave
                    VIP can only send out data bytes or null bytes
            
            - if both TSTRB and TKEEP are not implemented
                - DUT=master, VIP=slave: 
                    supply all 1's to TKEEP and TSTRB in the interface
                    
                - VIP=master, DUT=slave
                    VIP can only send out data bytes

            - if TLAST is not implemented
                - DUT=master, VIP=slave: 
                    supply 1'b1 / 1'b0 to TLAST signal in the interface based on the DUT interconnect topology
                    Can refer to spec 3.1.3 for more details.

                - VIP=master, DUT=slave
                    VIP shall be using the API with TLAST value based on DUT requirements

            - if TID, TDEST, TUSER are not implemented
                - DUT=master, VIP=slave: 
                    supply all 0's to TID, TDEST, TUSER in the interface

                - VIP=master, DUT=slave
                    VIP shall be using the API with setting '0s to TID, TDEST and/or TUSER                    
                
                
                    
- Tracker
    - User can see the packet details via tracker file, for example
        - packet type: whether it is a byte stream, continuous aligned stream, continuous unaligned stream, sparse stream, tlast packet.
        - data values: can see the values for all position bytes, data bytes, null bytes
        - tuser per byte or per transfer value display

- Debugability
    - Useful signals:
        - keep_strb_e               : Showing the byte is either position / data / null
        - interleaving_tid_tdest_x  : showing current interleaving TID->TDEST transactions

- Checker
    - Integrated ARM AXI Stream protocol checker with uvm_error