Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add axi master #1017

Open
wants to merge 54 commits into
base: master
Choose a base branch
from
Open

Add axi master #1017

wants to merge 54 commits into from

Conversation

DavidMartinPhios
Copy link

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

@DavidMartinPhios DavidMartinPhios changed the title AXI master Add axi master May 13, 2024
@DavidMartinPhios DavidMartinPhios marked this pull request as ready for review May 15, 2024 12:33
@LarsAsplund
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link
Author

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.

@LarsAsplund
Copy link
Collaborator

@DavidMartinPhios Please have a look at the updated standard rules. Rule 7 and 12 will make more sense when I have pushed supporting code but if you follow the rest of them you will have most of the work done. Compared to the previous draft standard, the rules have been updated to make better use of the identity package, VUnit events and packages.

LarsAsplund and others added 26 commits November 4, 2024 16:09
All generics are now integrated into a single parameter of type
apb_master_t.
The bus_master implementation will create an actor if null_actor is
given as parameter. So we don't have to do it in apb_master.
Keep it locked while there is unfinished work to do.
Major change to support optional pslverror signal of APB3.
Implementing rules 5 and 10.
The logger name is set according to the id field.
@DavidMartinPhios
Copy link
Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants