Add axi master

[DavidMartinPhios]

Added axi master with equally powerful implementation as axi lite master has

[LarsAsplund]

Thanks for getting this started. I'm aware of several implementations over the years but non of them made it to open source. It so happens that I have my eyes on yet another implementation in progress that may or not make it to the public. Even if that doesn't become open source, I can keep track of what features it requires such that the VC released by VUnit can meet those as well.

I will get back when I have more info.

[DavidMartinPhios]

Thanks for getting this started. I'm aware of several implementations over the years but non of them made it to open source. It so happens that I have my eyes on yet another implementation in progress that may or not make it to the public. Even if that doesn't become open source, I can keep track of what features it requires such that the VC released by VUnit can meet those as well.

I will get back when I have more info.

As you might figured out already this implementation is not yet finished. I am still working on it. Basically I am now adding the functionallity to each single signal. At the moment I have deticated reserved time to implement this specific VC. It would be nice to know if the work will get obsolete some day or be replaced by another implementation. Otherwise I will keep going with the implementation. Hopefully with your early review / support.

@LarsAsplund
Do you think that it is necessary to move the signals id, last, etc. to the bus_master record or is it ok to implement them around on a higher level as it is right now?

[LarsAsplund]

Since you've started and the other implementation may not make it to open source, I think we should continue on what you have. What I hope is to align on the required feature set such that you both can work on the open implementation in the end. I will come back and review a bit later,

[DavidMartinPhios]

Since you've started and the other implementation may not make it to open source, I think we should continue on what you have. What I hope is to align on the required feature set such that you both can work on the open implementation in the end. I will come back and review a bit later,

Thank you for the answer! I am currently working on the read burst behaviour. It is not finished yet but I think you could get an idea where the journey should go.

[DavidMartinPhios]

@LarsAsplund
Do you already had the change to review the axi master? At the moment a very basic version is implemented but it should provide basic read and write possibilities for burst and none burst.

[LarsAsplund]

I have yet to review it. The other implementation I'm keeping my eyes on is settling now so I think I will be in a position to review shortly and then make sure that the one you have is "feature compatible". With that I don't mean that it has to have all features but rather that the API is such that it can evolve and eventually cover all the things the other project is requiring. That way there is a chance that the two efforts can be merged in the end.

[DavidMartinPhios]

I have yet to review it. The other implementation I'm keeping my eyes on is settling now so I think I will be in a position to review shortly and then make sure that the one you have is "feature compatible". With that I don't mean that it has to have all features but rather that the API is such that it can evolve and eventually cover all the things the other project is requiring. That way there is a chance that the two efforts can be merged in the end.

@LarsAsplund
I will wait for your review before I continue further implementations. Just to be sure that it is not completely running in the wrong direction.

[DavidMartinPhios]

@LarsAsplund What is the sync interface mentioned by rule 9? Do I have to make some changes to my entity? If yes, could you please give me more information about what I have to change / implement?

[DavidMartinPhios]

@LarsAsplund Rule 9 and 11 are still not implemented. Do you have any examples or suggestions of what I have to implement there?

[LarsAsplund]

The sync interface is referring to https://github.com/VUnit/vunit/blob/master/vunit/vhdl/verification_components/src/sync_pkg.vhd which contains the wait_for_time and wait_until_idle procedures. You can provide your own implementation for these procedures by writing custom code in the VC that deals with the associated messages as they arrive. Alternatively, you can use the standard implementations provided by the handle_ procedures. There is one for each wait_ procedure and one that handles both of them. Have a look at this line for an example

vunit/vunit/vhdl/verification_components/src/uart_master.vhd

Line 56 in 51365a5

handle_sync_message(net, msg_type, msg);

. If the procedure is called with a message type not related to the wait_ messages, it will return without taking any action. If it is called with a wait_ related message it will take action and then return with the msg_type set to the special value message_handled. This means that the else branch in the following if statement will be entered and unexpected_msg_type is called. That is no problem because that procedure treats message_handled as a special case and will just return.

[LarsAsplund]

The standard configuration is a convenience provided by https://github.com/VUnit/vunit/blob/master/vunit/vhdl/verification_components/src/vc_pkg.vhd. I just merged it to master so you need to rebase your branch. The idea is that you use create_std_cfg in your constructor and store the resulting standard configuration in your handle. It contains the common objects and configurations required by other rules, the actor for example. This means that loggers, checkers, and actors do not need to be parameters to the constructor, they are all created by create_std_cfg from the id parameter, or from the other parameters to create_std_cfg if an id isn't provided. From the standard configuration in the handle you get the contents using functions such as get_actor which you also find in that file.

Also note the new unexpected_msg_type procedure which takes the standard configuration as the second parameter. From that it can determine if an unexpected message type should cause an error or be ignored.

By providing a get_std_cfg function, it is possible to get the standard configuration from the handle and then the internal information from the standard configuration. If you provided an id when creating the handle, there are other ways of getting this information so this is more crucial for the cases where id wasn't provided. Let's say you want to get the root logger from a VC instance such that you can enable all its debug messages:

show(get_logger(get_std_cfg(vc_handle)), display_handler, debug)