Optional ports on AXI stream transmitter and receiver cannot be left unused

[Hassan]

I have used the AXI stream testbench to create my own for my design. The thing is, I do not need to use all the optional signals that are part of the AXI Stream interface. I am only using these on my DUT: valid, enable, data, user. I am not using these on my DUT: TID, TDest, TUser, TStrb, TKeep, TLast.

For the unused AXI stream signals on my DUT I did the following:
-> For the transmitter, first I left the ports out. However, this generate error. Then I made all ports open explicitly like this.
AXI_ST_TX : AxiStreamTransmitter
generic map (
INIT_USER => INIT_USER,
tperiod_Clk => tperiod_Clk,
tpd_Clk_TValid => tpd,
tpd_Clk_TUser => tpd,
tpd_Clk_TData => tpd
)
port map (
— Globals
Clk => clk,
nReset => rstn,

— AXI Stream Interface
— From TB Transmitter to DUT Receiver
TValid => s_axis_tvalid,
TReady => s_axis_tready,
TUser => s_axis_tdata,
TData => s_axis_tuser,

TID => open,
TDest => open,
TStrb => open,
TKeep => open,
TLast => open,

— Testbench Transaction Interface
TransRec => StreamTxRec
);

-> For the receiver, first I left the ports out. However, this generate error. Then I tied all ports to ground explicitly like this.
AXI_ST_RX : AxiStreamReceiver
generic map (
INIT_USER => INIT_USER,
tperiod_Clk => tperiod_Clk,
tpd_Clk_TReady => tpd
)
port map (
— Globals
Clk => clk,
nReset => rstn,

— AXI Stream Interface
— From TB Receiver to DUT Transmitter
TValid => m_axis_tvalid,
TReady => m_axis_tready,
TUser => m_axis_tdata,
TData => m_axis_tuser,

TID => (others=>’0′),
TDest => (others=>’0′),
TStrb => (others=>’0′),
TKeep => (others=>’0′),
TLast => ‘0’,

— Testbench Transaction Interface
TransRec => StreamRxRec
);

I am getting these errors for all these ports in QuestaSim:
(vcom-1036) Formal port “TID” of mode OUT has OPEN or no actual associated with it.
(vcom-1036) Formal port “TDest” of mode OUT has OPEN or no actual associated with it.
(vcom-1036) Formal port “TStrb” of mode OUT has OPEN or no actual associated with it.
(vcom-1036) Formal port “TKeep” of mode OUT has OPEN or no actual associated with it.
(vcom-1076) OTHERS choice cannot be used in unconstrained array aggregate.
(vcom-1076) OTHERS choice cannot be used in unconstrained array aggregate.
(vcom-1076) OTHERS choice cannot be used in unconstrained array aggregate.
(vcom-1076) OTHERS choice cannot be used in unconstrained array aggregate.

My conclusion is that, since these ports (except TLast) are actually unconstrained, this causes the simulation tool to not understand how to interpet “open” and “others=>’0′”. This is actually a serious problem. I do not think that it has been discussed in the “AxiStream Verification Component User Guide for Release 2022.01”.

What could solve this? We could just use dummy signal and connect it to the output and the inputs. Or, the verification component can be changed so it uses generics. This information should be written into the guide since many people might not even be used to this VHDL-2008 feature that permits unconstrained ports.

[Hassan]

One more thing. I created the dummy signals but the forgot to update this line:

constant AXI_PARAM_WIDTH : integer := TID_MAX_WIDTH + TDEST_MAX_WIDTH + TUSER_MAX_WIDTH + 1 ;

I had to add the TID_MAX_WIDTH + TDEST_MAX_WIDTH + TUSER_MAX_WIDTH back into them. Certainly the setup feels rather fidly.

[Jim Lewis]

Hi Hassan
The AXI interface has a number of optional signals. How to handle these is the interesting proposition. Their width can be configured. The current VC leaves them unconstrained. This means they have to be connected, even if unused and connected to a 0 width std_logic_vector(0 downto 1).

That said, can their impact be minimized. The package AxiStreamGenericSignalsPkg is meant to be instantiated as a local package in the testbench. This will create all of these signals with the proper sizing. Furthermore, if you have two of these packages, you can reference the signals internal to them using packageInstanceName.SignalName notation. At one point, one of the testbenches worked this way, but it was replaced with a simpler implementation since it was crashing some tools. I think it is time to add that test case back as it will simplify situations such as yours.

Adding generics to the ports does not seem like it would simplify things too much. OTOH, making the axi stream port a record type with unconstrained elements – like AXI4 – might simplify it in that only one signal would need to be declared.

Best Regards,
Jim

[Hassan]

I guess converting it into record is the correct way forward in that case, since that is how it works with the memory mapped AXI4 VC.

So is there any example that uses the AxiStreamGenericSignalsPkg at the moment?

[Jim Lewis]

There was. It was removed as it did not work in one of the vendors. I will need to add it back.

[Hassan]

The USER can be assigned as follows:
SetAxiStreamOptions(StreamTxRec, DEFAULT_USER, User);

Or, within the send and sendburst commands:
Send(StreamTxRec, X”AAAA_AAAA”, ID1 & DEST1 & USER1 & ‘0’, TRUE) ;
SendBurst(StreamTxRec, 8, ID2 & DEST2 & USER2 & ‘1’) ;

The check can be done like this:
Check(StreamRxRec, X”BBBB_BBBB”, ID1 & DEST1 & USER1 & ‘0’) ;
CheckBurst(StreamRxRec, 8, ID1 & DEST1 & USER1 & ‘1’) ;

Now there are basically two questions here.

1. Why do we need SetAxiStreamOptions when we can assign the value of ID & DEST & USER in the Send* commands?
2. What are the ‘0’ and ‘1’ being concatenated after USER? I assume that this is TLAST. It is not clear why it is being appended as a bit rather than via a variable.
3. How is GetAxiStreamOptions supposed to be used when checking for the value of USER?

[Hassan]

4. The AXI stream receiver gets the ID, DEST and USER from the transmitter VC. When it gets the data, we can access what the transmitter sent it. What then is the meaning of SetAxiStreamOptions for the receiver? It should only have GetAxiStreamOptions just like it has Get and no Send command. It is a receiver after all.

[Hassan]

I believe that the GetAxiStreamOptions could just be used with DEFAULT_ID, DEFAULT_DEST, DEFAULT_USER. However, I am not sure why this is not done anywhere in any testbench that comes with OSVVM.

[Author]

Posts