Leaving TID, TDest, TUser, TData, TStrb, TKeep Ports Unconnected

[JimLewis]

With AxiStream, the ports TID, TDest, TUser, TData, TStrb, TKeep vary with the implementation.

Currently the AxiStream VC define these as unconstrained array ports:

  port (
. . .
    TID       :  <dir> std_logic_vector ;
    TDest     :   <dir> std_logic_vector ;
    TUser     :   <dir> std_logic_vector ;
    TData     :   <dir> std_logic_vector ;
    TStrb     :   <dir > std_logic_vector ;
    TKeep     :  <dir > std_logic_vector ;
. . .
  ) ;

The implication of these being unconstrained ports forces us to create a connection for them
in the testbench whether we are using them or not.

We could add generics to size TID, TDest, TUser and TData. This would then constrain TStrb
and TKeep to TData'length/8. Is this any better than just connecting something to them.

• Case 1: All ports are already connected. Specifying generics then is extra work.
• Case 2: Only TData is used. Specifying the generics is approximately the same amount of work as connecting a signal.

It seems then that adding generics would result in extra work, which would be undesirable.

With VHDL-2019, allowing ports to be ordered, http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/LCS2016_086, will allow us to derive the port size of TStrb and TKeep from TData. That will allow these IO to be unconnected.

Maybe VHDL-202X should allow make unconstrained outputs that are not connected to have 0 length. I added this as issue: https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/253, however, the issue is incomplete and needs testing.

Thoughts?

[JimLewis]

One option to work around this is to use AxiStreamGenericSignalsPkg.vhd and then do a local instance of it.
At one point in time the AxiStream testbench had a local instance of AxiStreamGenericSignalsPkg in it, however, it did not work in some simulators, so it was removed from the main AxiStream testbench. That said, while some non-compliant tools may not support this VHDL-2008 coding style, I think it is reasonable to create another testbench directory to test that solution and track which simulators support it and which do not.

Another option here is to create a second VC that uses record ports. Having more VC variations to support is not desirable though.