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

reset for axi_stream_master #422

Merged

Conversation

olafvandenberg
Copy link

added reset output to use when the axi_stream_master is generating the reset.
changed wait until idle construction to use a notify from the bus process so that we are sure all transactions (including the reset) have been handled.
added checking of reset input on places where it is required so that a reset is handled properly in the master.
added axi_stream_reset to vci.
added reset input to axi_stream_slave.vhd.
added basic test for reset functionality.

added reset output to use when the axi_stream_master is generating the reset.
changed wait until idle construction to use a notify from the bus process so that we are sure all transactions (including the reset) have been handled.
added checking of reset input on places where it is required so that a reset is handled properly in the master.
added axi_stream_reset to vci.
added reset input to axi_stream_slave.vhd.
added basic test for reset functionality.
Copy link
Contributor

@go2sh go2sh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the addition of the reset to the master, but i would keep the reset generation out of it. Instead add a new component. which generates resets. (e.g. with synchronous asynchronous assert). This way it keeps a nice separation of functionality. In most of the designs I know the reset comes from some other source and not the master itself.


notify_bus_process_done <= '1';
wait until notify_bus_process_done = '1';
notify_bus_process_done <= '0';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I'am not sure, why this is needed. waiting for tvalid = '0' and aclk should be sufficient.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was necessary to be able to issue a reset 'request' and follow it up with a wait_until_idle to wait for it to complete.
When just adding a areset_out_n = '1' there was a timing hole and the wait_until_idle would complete to early.

@kraigher
Copy link
Collaborator

@go2sh Has a point. It would be more modular if there was a separate reset generator VC and the axi stream just had reset as an input? What do you say @olafvandenberg?

@olafvandenberg
Copy link
Author

olafvandenberg commented Dec 12, 2018

Ok, I agree, sound likes a plan, I'll need some time for it though.
I've made the changes.
Perhaps it is better to make it not a 'reset' generator VC but just an IO VC, that can be used generally for separate IOs (?)

replaced reset out / reset in, with single reset input.
adapted testbench.
@kraigher kraigher merged commit a7f7717 into VUnit:master Dec 13, 2018
@kraigher
Copy link
Collaborator

Yes a to drive a reset is nothing special so an general io vc is probably smart.

@olafvandenberg olafvandenberg deleted the feature/add_reset_to_axi_streaming_master branch December 13, 2018 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants