Running AXI4 Simulation from OSVVM Libraries repository

[Hassan]

So I am specifically interested in learning to use the BFMs that come with OSVVM. Right now it is the AXI4 MM and AXI4 Stream BFM. There are several questions that need to be answered some of which I have answers for. Anyway, lets start from the beginning.

I downloaded the OSVVM libraries using this: $ git clone –recursive https://github.com/osvvm/OsvvmLibraries

Now I get a whole lot of .pro files and folders. The readme at the top level of the OsvvmLibraries does not specifically describe what all these folders and .pro files are and how they are supposed to be used. If I read the documentation it goes like this: run startup.tcl and then build OsvvmLibraries and then build OsvvmLibraries/AXI4/Axi4/RunDemoTests.pro.

Now my first two questions:
1. What are all those scripts inside the Scripts folder of the OsvvmLibraries? Are they required by user for every user project? I was hoping to see a make file but Osvvm does not seem to use that.
2. We have RunAllTests.tcl, RunAllTestsVti.tcl and RunDemoTests.tcl. Why do we need all these in the AXI folder and also the OsvvmLibraries folder?
3. For the AXI4 MM BFM, in the src folder we have these files Axi4Manager.vhd, Axi4Manager_xilinx.vhd, Axi4ManagerVti.vhd. Why do we need different versions of the same thing as different source files?

Ultimately I am trying to understand the minimum code required to run a basic test for AXI4 master/slave from the OsvvmLibrarires.

[Jim Lewis]

The scripting provided as part of OSVVM is hierarchical. If we take a look at $OsvvmLibraries/OsvvmLibraries.pro, we will see:

include ./osvvm/osvvm.pro
include ./Common/Common.pro

if {[DirectoryExists UART]} { 
  include ./UART/UART.pro
}
if {[DirectoryExists AXI4]} { 
  include ./AXI4/AXI4.pro
}
if {[DirectoryExists DpRam]} { 
  include ./DpRam/DpRam.pro
}
if {[DirectoryExists Ethernet]} { 
  include ./Ethernet/Ethernet.pro
}
if {[DirectoryExists VideoBus_LouisAdriaens]} { 
  include ./VideoBus_LouisAdriaens/VideoBus.pro
}
if {[DirectoryExists SPI_GuyEschemann]} { 
  include ./SPI_GuyEschemann/SPI.pro
}
if {$::osvvm::ToolNameVersion ne "XSIM-2023.2"} {
  if {[DirectoryExists CoSim]} { 
    include ./CoSim/CoSim.pro
  }
}

Each directory contains a script (*.pro) to analyze the files in it. By convention that file is named either Directory.pro (historical) or build.pro (newer). The build/include command sources a *.pro script and replace TCL’s source (and the tool vendors do). When called with build/include, files specified in a *.pro have a path relative to the location of the script. This makes it easy to organize VC and the OSVVM libraries as you see fit as the only thing that needs to know a path is a high level script.

The scripts (*.pro) are a procedure layer (hence pro) that runs on top of tcl. So the scripts are allowed to include tcl as needed. The if statements in the script check and see if a given submodule (lower level repository) is present and if it is run its script to analyze it.

The osvvm.pro and common.pro are not optional, but the rest are and are only compiled if they are present. Generally though there is no disadvantage to including all of the OsvvmLibraries submodules as it takes less than 60 seconds to analyze.

Now for your questions:
> 1. What are all those scripts inside the Scripts folder of the OsvvmLibraries? Are they required by user for every user project? I was hoping to see a make file but Osvvm does not seem to use that.

In general, if you are just using OsvvmLibraries and not editing it, you only need to compile it once. So you run the build $OsvvmLibraries/OsvvmLibraries.pro one time as you are establishing your project (or each time a CI/CD regression is running). It takes less than 60 seconds.

Makefiles remove redundant compilations on portions of code you are actively developing. If you are not working on the OsvvmLibraries themselves, then there is no need for a makefile – you are going to build OSVVM one time.

As a developer, a make file would be worth creating if compilation took some tangible amount of time. It doesn’t. So I have not bothered. Since VHDL has libraries, VHDL tools know the dependencies – tools could internally implement a make capability.

> 2a. We have RunAllTests.pro, RunAllTestsVti.pro and RunDemoTests.pro.

OsvvmLibraries includes the OSVVM test suite used to test each VC. The regression test suite for a given VC is named RunAllTests.pro. A demo test suite is provided in RunDemoTests.pro.

The RunAllTestsVti.pro are used to test the Virtual Transaction Interface (VTI) version of the AXI4 and AxiStream verification components. The VTI VC connect to the test sequencer using external names (see AXI4/Axi4/testbenchVti) for an example of how this works. It is also documented in the Axi4_VC_user_guide.pdf in the OsvvmLibraries/Documentation directory. The VTI VC are required when a VC is internal to the DUT, such as with Xilinx Zynq.

Other than the interface, the VTI VC are identical to the port based VC. Hence the differences in the tests are in the testbench and testbenchVti directories and the use the same TestCtrl architectures as test cases.

> 2b. Why do we need all these in the AXI folder and also the OsvvmLibraries folder?
The test cases are hierarchical. This allows you to do, build $OsvvmLibraries/RunAllTests.pro to run everything that is present in your distribution (meaning if you do not have the UART repository, its test cases will not run).

> 3. For the AXI4 MM BFM, in the src folder we have these files Axi4Manager.vhd, Axi4Manager_xilinx.vhd, Axi4ManagerVti.vhd. Why do we need different versions of the same thing as different source files?

Axi4Manager.vhd is the port based version of the VC. It is what we originally built and as a result maintain. The Axi4ManagerVti.vhd creates the transaction API as an internal signal (named TransRec in the entity declarative region) that the test sequencer (TestCtrl) connects to using an external name. Again this is to allow the Axi4ManagerVti to be internal to a Xilinx DUT and the TestCtrl to connect to it without adding a signal to the DUT.

The Axi4Manager_xilinx.vhd is an experimental version for Xilinx. We are trying to bring up all of OSVVM within Xilinx XSim. Sometimes this requires tool specific work arounds. That said, we have most/all of the OSVVM utility library (osvvm) working (except for some of the resolution functions). Running the VC is currently problematic, but we have all of our blocking issues submitted to Xilinx and are hopeful for a solution in 2024.

Hopefully the Axi4Manager_xilinx.vhd will go away. The Axi4Manager.vhd and Axi4ManagerVti.vhd are here to stay.

[Hassan]

Thanks Jim. I know you are busy but still taking time out to write here.

With VUnit I can pass a switch to the run.py and get list of tests and then run a specific test. I can choose whether to run it in in GUI mode or batch mode. How can I do that with OSVVM AXI4 tests?

I can see that with OSVVM, each test is a different architecture of the same entity. But can OSVVM list tests like we do with VUnit and then run a specific test in GUI mode of QuestaSim?

[Jim Lewis]

> With VUnit I can pass a switch to the run.py and get list of tests and then run a specific test. I can choose whether to run it in in GUI mode or batch mode. How can I do that with OSVVM AXI4 tests?

> I can see that with OSVVM, each test is a different architecture of the same entity. But can OSVVM list tests like we do with VUnit and then run a specific test in GUI mode of QuestaSim?

Do you like this feature?

I have not found a use case for that at this point.

I start testing with a test plan and a list of items that identify what needs to be tested.

In a testbench directory (often named testbench), I create the test harness that connects the DUT, Verification Components, and Test Sequencer (often named TestCtrl). I put each separate test harness in a separate directory. I put each in a separate library – this allows every testbench to use the name TestCtrl for the test sequencer. I create a script that analyzes (compiles) the test harness – often named either testbench.pro (matching the directory name) or build.pro.

If I have just a few test cases, I will put them in the same directory as the test harness – this is what is done in OsvvmLibraries/UART/testbench.

If I have many test cases or have multiple test harnesses that will use the test cases, I put the test cases in a separate directory. In both Axi4 and AxiStream the test cases are in the TestCases directory (see OsvvmLibraries/AXI4/Axi4/TestCases). These too have a script that analyses and runs them – such as TestCases.pro (again matching the directory name) or build.pro.

Test cases are an architecture of the TestCtrl entity. Generally each test architecture has a configuration declaration with it – put in the bottom of the file. Since the configuration declaration runs the test case, I name it with a “Tb” or “tb_” prefix and that is what I tell the simulator to run. The suffix of the name is generally the test case name – which most often also matches the architecture name.

The first run of a test case is done interactively with the following three steps:

TestName  Tb_Test1
analyze   Tb_Test1.vhd
simulate Tb_Test1

Here Tb_Test1 is the name that the VHDL code gives the test case, with the SetTestName(“Tb_Test1”) in the VHDL code. The file Tb_Test1.vhd contains both the test architecture (named Test1) and the configuration declaration (at the bottom and named Tb_Test1). If you follow this naming methodology, then to create test2, copy Tb_Test1.vhd to Tb_Test2.vhd and inside the file replace Test1 with Test2 and you are good to go (no additional configuration declaration to create)

If you follow the steps in the above paragraph, then you can run the test with the shorthand:
RunTest Tb_Test1.vhd

Once I get a test case running, I add it to a the script that is in the same directory as the Test Cases (as noted above, this may be either the testbench or TestCases – depending on the number of test cases).

Once a test case is run and passes, it is only run as a regression unless it fails in regression and requires debugging.

Coming back to your question then, either
1) I am in the process of developing a test case and I run it interactively, so the name is fresh in my mind or
2) The test case failed in regression, so I have its name and I run it interactively.

So while I think the VUnit capability is cool, I have not found a use case (need) for it.

[Jim Lewis]

As an addendum to my last comment …
Note there are shortcuts when calling the scripts via include/build. So the following are equivalent:

build $OsvvmLibraries/OsvvmLibraries.pro
build $OsvvmLibraries/OsvvmLibraries      ; # Automatically adds .pro extension
build $OsvvmLibraries                     ; # looks for OsvvmLibraries.pro or build.pro in the directory

[Jim Lewis]

Getting back to your question again, if the test cases are compiled, OSVVM can do

LinkLibraryDirectory      ; # Make libraries in the OSVVM library directory visible - not necessary after a build
ListLibraries              ; # Lists the libraries OSVVM knows about.
vdir -lib <libraryName>    ; # Questa/ModelSim & RivieraPRO/ActiveHDL
library <libraryName>      ; # make libraryName the current working library - not need if it is already
simulate <designUnitName>  ; # run the configuration name

VUnit has a more sophisticated capability than this as I think it looks at VHDL files, but again, I don’t really have a use model for this.

[Hassan]

Jim I agree with you that once a test passes, it will never ever be run interactively and only in regression. I agree that the only time a test is run interactively is when a test is being developed or it fails and a closer look at waves is required.

The simple answer to the question is that to know what tests exist, we look at the test plan or in this case for the AXI4 we can look at the TestCases folder. Does OsvvmLibraries contain test plan that describes what specific tests exist? I have not found one.

My mind is made up according to how VUnit works so since OSVVM is different in many aspects, I am trying to understand the differences and basically learn how to use the BFMs.

I will follow your instructions and see how far I can get.

[Hassan]

First lets look at RunDemoTests.pro

TestSuite Axi4Full
library osvvm_TbAxi4

if {$::osvvm::ToolNameVersion ne "XSIM-2023.2"}  {
  include ./testbench

  # Make TestCases the frame of reference
  set ::osvvm::CurrentWorkingDirectory [file join $::osvvm::CurrentWorkingDirectory TestCases]
  RunTest  TbAxi4_DemoMemoryReadWrite1.vhd
  RunTest TbAxi4_ManagerRandomTiming1.vhd 
  RunTest TbAxi4_ManagerMemoryRandomTiming1.vhd 
  RunTest  TbAxi4_MemoryBurstPattern1.vhd
} else {
  SkipTest Axi4VC "AXI4 VC not working in XSIM"
}

Now lets look at RunAllTests.pro

TestSuite Axi4Full
library osvvm_TbAxi4

if {$::osvvm::ToolNameVersion ne "XSIM-2023.2"}  {
  include ./testbench
  include ./TestCases
  include ./testbench_MultipleMemory
  # include ./testbench_interrupt  ; # moved to OsvvmLibraries/Common/TbInterrupt
} else {
  SkipTest Axi4VC "AXI4 VC not working in XSIM"
}

This second script makes no mention of the RunTest TCL command. How it is actually calling TCL scripts inside the testbench, TestCases and testbench_MultipleMemory folders that contain TCL scripts and these contain the RunTest commands.

These TCL commands TestSuite, RunTest and SkipTest appear to be defined in the OsvvmProjectScripts.tcl. There are other commands like build, analyze, include for which I have found no description anywhere. Is there a detailed exposition of the TCL API anywhere or it is considered not important for the end user?

Also, I see that two libraries are created: osvvm_tbaxi4, osvvm_tbaxi4_multiplememory. How come testbench test case/sequence libraries are being created for the AXI4 but not for Ethernet, UART and DPRAM? These other ones have RTL library but not one for the testbench files. The AXI testbench libraries have the largest size among all the libraries created by QuestaSim after compilation.

[Hassan]

OK, so here is how I am able to run specific test.

First I goto a suitable location where QuestaSim can save its generated files. In this case I did

cd {E:\My_Designs\FPGA\OsvvmLibraries}

Then I ran the following commands:

source ./Scripts/StartUp.tcl
include ./osvvm/osvvm.pro
include ./Common/Common.pro
include ./AXI4/AXI4.pro

library osvvm_TbAxi4
RunTest  TbAxi4_DemoMemoryReadWrite1

The StartUp.tcl is important since it basically loads the TCL commands that are used by other scripts, into the simulation environment. The next three include commands are compiling files into specific libraries. All three commands are running prexisting scripts that compile files from specific locations. I do not understand how the library command suddenly creates a new library that is full of precompiled files since the earlier scripts did not compile them. This is a bit wierd. But anyway, then I am able to run a specific test called TbAxi4_DemoMemoryReadWrite1.

The TbAxi4_DemoMemoryReadWrite1 contains axi4manager, axi4monitor, axi4memory along with the TestCtrl entity that has the configuration to compile the TbAxi4_DemoMemoryReadWrite1 test sequence architecture.

Since I am using QuestaSim, I am able to restart the test and run it again by using:
restart -f; run -all;

If I need any files to be compiled again like the testbench or DUT files, I guess I could just recall the AXI4.pro again or run the analyze command on the specific file. It seems that the analyze command is created by the OSVVM via the StartUp.tcl to compile source files.

[Jim Lewis]

> Does OsvvmLibraries contain test plan that describes what specific tests exist?

I have not published one. I have it in my notebook. It would be a good idea to publish it.

> These TCL commands TestSuite, RunTest and SkipTest appear to be defined in the OsvvmProjectScripts.tcl. There are other commands like build, analyze, include for which I have found no description anywhere. Is there a detailed exposition of the TCL API anywhere or it is considered not important for the end user?

Script documenation is in the Script_user_guide.pdf in OsvvmLibraries/Documentation. Currently all of the OSVVM API (TestSuite, RunTest, SkipTest, build, analyze, include, build) are defined in OsvvmProjectScripts.tcl – it is large and it may be refactored in the future.

Full documentation on OSVVM starts with README.rst (this reads better at https://github.com/OSVVM/Documentation/tree/main – see bottom of page) or if you prefer pdf, start with OSVVM_Overview.pdf also in OsvvmLibraries/Documentation.

> This second script (RunAllTests.pro) makes no mention of the RunTest TCL command.

OSVVM’s include and build replace tcl’s “source” and eda tool macro’s “do”. Use build from the simulator command line. Use include from inside a *.pro script.

The “include ./TestCases” in RunAllTests.pro is short-hand for “include ./TestCases/TestCases.pro”. If you look in ./TestCases/TestCases.pro you will find the

> Also, I see that two libraries are created: osvvm_tbaxi4, osvvm_tbaxi4_multiplememory. How come testbench test case/sequence libraries are being created for the AXI4 but not for Ethernet, UART and DPRAM?

For those the library and test suite are in the testbench script. When there are multiple testbench directories that run in different libraries then the library and TestSuite need to be where the testbench directories are.

> I do not understand how the library command suddenly creates a new library that is full of precompiled files since the earlier scripts did not compile them.

The library command creates a library if it does not exist, if it does exist, create a mapping to it, and then activate that library such that future calls to analyze (or RunTest) compile things into that library. Hence, if you have already done RunAllTests for a given directory at some time in the past, its library will exist and anything previously compiled into that library will still exist.

> The TbAxi4_DemoMemoryReadWrite1 contains axi4manager, axi4monitor, axi4memory along with the TestCtrl entity that has the configuration to compile the TbAxi4_DemoMemoryReadWrite1 test sequence architecture.

The TbAxi4_DemoMemoryReadWrite.vhd contains an architecture of TestCtrl and the configuration declaration TbAxi4_DemoMemoryReadWrite1 that binds the test architecture to the test harness for simulation. The test architecture has a separate process for each independent interface in the test harness. The test harness contains instances of the DUT, VC (axi4manager, axi4memory), and TestCtrl.

Do some reading starting with the OSVVM_Overview.pdf then follow the other documents. Alternately SynthWorks offers classes on OSVVM: Advanced VHDL Testbenches and Verification see: https://synthworks.com/vhdl_testbench_verification.htm. We have an on-line class coming up in early June. We have in person classes coming up in late June in Germany and September in UK.

> If I need any files to be compiled again like the testbench or DUT files, I guess I could just recall the AXI4.pro again or run the analyze command on the specific file.

Generally I setup the build.pro or OsvvmLibraries.pro files to compile all the sources that are the OSVVM library sources. I setup the RunAllTests.pro to compile the test harness, and compile and run test cases. When I am running test cases, I run them interactively as I am developing the test cases and then for regression, I run them by creating a RunAllTests.pro for that specific test harness or suite of test cases.

Generally for your design, you will run OsvvmLibraries.pro one time to build the OSVVM libraries. You will need to create a DUT.pro to build your DUT, a testbench.pro to build your test harness, and a VC.pro to build your verification components. When you fix a design bug, you will need to rerun DUT.pro and testbench.pro – hence the reason why we build VC.pro separately. The compilation is fast enough that it is faster to run a script that builds many things than to just the things that need analyzed.

I apologize if I missed any of your questions, please repost them if I did.

[Jim Lewis]

> Does OsvvmLibraries contain test plan that describes what specific tests exist?

I have not published one. I have it in my notebook. It would be a good idea to publish it.

> These TCL commands TestSuite, RunTest and SkipTest appear to be defined in the OsvvmProjectScripts.tcl. There are other commands like build, analyze, include for which I have found no description anywhere. Is there a detailed exposition of the TCL API anywhere or it is considered not important for the end user?

Script documenation is in the Script_user_guide.pdf in OsvvmLibraries/Documentation. Currently all of the OSVVM API (TestSuite, RunTest, SkipTest, build, analyze, include, build) are defined in OsvvmProjectScripts.tcl – it is large and it may be refactored in the future.

Full documentation on OSVVM starts with README.rst (this reads better at https://github.com/OSVVM/Documentation/tree/main – see bottom of page) or if you prefer pdf, start with OSVVM_Overview.pdf also in OsvvmLibraries/Documentation.

> This second script (RunAllTests.pro) makes no mention of the RunTest TCL command.

OSVVM’s include and build replace tcl’s “source” and eda tool macro’s “do”. Use build from the simulator command line. Use include from inside a *.pro script.

The “include ./TestCases” in RunAllTests.pro is short-hand for “include ./TestCases/TestCases.pro”. If you look in ./TestCases/TestCases.pro you will find the

> Also, I see that two libraries are created: osvvm_tbaxi4, osvvm_tbaxi4_multiplememory. How come testbench test case/sequence libraries are being created for the AXI4 but not for Ethernet, UART and DPRAM?

For those the library and test suite are in the testbench script. When there are multiple testbench directories that run in different libraries then the library and TestSuite need to be where the testbench directories are.

> I do not understand how the library command suddenly creates a new library that is full of precompiled files since the earlier scripts did not compile them.

The library command creates a library if it does not exist, if it does exist, create a mapping to it, and then activate that library such that future calls to analyze (or RunTest) compile things into that library. Hence, if you have already done RunAllTests for a given directory at some time in the past, its library will exist and anything previously compiled into that library will still exist.

> The TbAxi4_DemoMemoryReadWrite1 contains axi4manager, axi4monitor, axi4memory along with the TestCtrl entity that has the configuration to compile the TbAxi4_DemoMemoryReadWrite1 test sequence architecture.

The TbAxi4_DemoMemoryReadWrite.vhd contains an architecture of TestCtrl and the configuration declaration TbAxi4_DemoMemoryReadWrite1 that binds the test architecture to the test harness for simulation. The test architecture has a separate process for each independent interface in the test harness. The test harness contains instances of the DUT, VC (axi4manager, axi4memory), and TestCtrl.

Do some reading starting with the OSVVM_Overview.pdf then follow the other documents. Alternately SynthWorks offers classes on OSVVM: Advanced VHDL Testbenches and Verification see: https://synthworks.com/vhdl_testbench_verification.htm. We have an on-line class coming up in early June. We have in person classes coming up in late June in Germany and September in UK.

> If I need any files to be compiled again like the testbench or DUT files, I guess I could just recall the AXI4.pro again or run the analyze command on the specific file.

Generally I setup the build.pro or OsvvmLibraries.pro files to compile all the sources that are the OSVVM library sources. I setup the RunAllTests.pro to compile the test harness, and compile and run test cases. When I am running test cases, I run them interactively as I am developing the test cases and then for regression, I run them by creating a RunAllTests.pro for that specific test harness or suite of test cases.

Generally for your design, you will run OsvvmLibraries.pro one time to build the OSVVM libraries. You will need to create a DUT.pro to build your DUT, a testbench.pro to build your test harness, and a VC.pro to build your verification components. When you fix a design bug, you will need to rerun DUT.pro and testbench.pro – hence the reason why we build VC.pro separately. The compilation is fast enough that it is faster to run a script that builds many things than to just the things that need analyzed.

I apologize if I missed any of your questions, please repost them if I did.

[Hassan]

Thanks Jim. Now for a simpler question.

Often the BFM is going to used with a System created using Platform Designer in Quartus or the Block Design in Vivado.

For Platform Designer this means that we create a tcl file that tells the tool what signals make up the AXI interface so it can link them with the complementing master/slave port and create the interconnect.

For Block Design this means that we create special file used by Vivado that tells the tool what signals make up the AXI interface so it can link them with the complementing master/slave port and create the interconnect.

Now here, the BFM does not have separate signals but contains this:

— AXI Manager Functional Interface
AxiBus : inout Axi4RecType ;

How exactly is the user expected to connect to this or use this BFM inside the Platform Designer or Block Design?

[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

[Hassan]

I was suspecting that the only method will be to use a wrapper that only uses standard logic signals and then the Platform Designer and Block Designer should not have any issue. Its amazing how poor the hardware domain EDA tools are.

[Jim Lewis]

Don’t despair too much at least for Xilinx I think it will be coming. They have implemented the VHDL-2019 feature called interfaces – which is a record + mode view. A mode view specifies the IO direction of each element the record. With this, they will need to support it through all of their tools, such as Platform and Block Designer. I suspect you just need to file a bug report against it.

[Author]

Posts