Reply To: Running AXI4 Simulation from OSVVM Libraries repository

[Jim Lewis]

I am not sure how Xilinx deals with this, however, for any composite port, VHDL allows you to map composites (records or arrays) element by element, below done as a formal:

  ------------------------------------------------------------
  Manager_1 : Axi4Manager
  ------------------------------------------------------------
  port map (
    -- Globals
    Clk         => Clk,
    nReset      => nReset,

    -- AXI Manager Functional Interface
    AxiBus.WriteAddress.Addr      =>     mAwAddr,
    AxiBus.WriteAddress.Prot      =>     mAwProt,
    AxiBus.WriteAddress.Valid     =>     mAwValid,
    AxiBus.WriteAddress.Ready     =>     mAwReady,
    AxiBus.WriteAddress.ID        =>     mAwID,
    AxiBus.WriteAddress.Len       =>     mAwLen,
    AxiBus.WriteAddress.Size      =>     mAwSize,
    AxiBus.WriteAddress.Burst     =>     mAwBurst,
    AxiBus.WriteAddress.Lock      =>     mAwLock,
    AxiBus.WriteAddress.Cache     =>     mAwCache,
    AxiBus.WriteAddress.QOS       =>     mAwQOS,
    AxiBus.WriteAddress.Region    =>     mAwRegion,
    AxiBus.WriteAddress.User      =>     mAwUser,
    
    -- ... map remaining AXI individual signals  

    -- Testbench Transaction Interface
    TransRec    => ManagerRec
  ) ;

or mapping a record on the actual side:

  ------------------------------------------------------------
  Axi4PassThru_1 : Axi4PassThru 
  ------------------------------------------------------------
  port map (
  -- AXI Manager Interface - Driven By PassThru
    -- AXI Write Address Channel
    mAwAddr       => AxiBus2.WriteAddress.Addr,
    mAwProt       => AxiBus2.WriteAddress.Prot,
    mAwValid      => AxiBus2.WriteAddress.Valid,
    mAwReady      => AxiBus2.WriteAddress.Ready,
    mAwID         => AxiBus2.WriteAddress.ID,
    mAwLen        => AxiBus2.WriteAddress.Len,
    mAwSize       => AxiBus2.WriteAddress.Size,
    mAwBurst      => AxiBus2.WriteAddress.Burst,
    mAwLock       => AxiBus2.WriteAddress.Lock,
    mAwCache      => AxiBus2.WriteAddress.Cache,
    mAwQOS        => AxiBus2.WriteAddress.QOS,
    mAwRegion     => AxiBus2.WriteAddress.Region,
    mAwUser       => AxiBus2.WriteAddress.User,

If Xilinx cannot handle this, the Axi4Manager VC may need to be encapsulated inside of wrapper layer of hierarchy (an entity which instances the Axi4Manager VC and has the ports done in a Xilinx compatible manner.

This makes more sense to do this when the higher level is an Zynq or MPSoC which has multiple masters and multiple subordinates. Zynq and MPSoC blocks would have the transaction records as internal signals – see the Axi4ManagerVti and testbenchVti for examples of using this – it should also be in the Axi4_VC_user_guide.pdf