AXI4 VIP development and integration#688
Conversation
01fb3d1 to
3863316
Compare
rswarbrick
left a comment
There was a problem hiding this comment.
Thank you very much for doing this (and getting my completely untested code working...)
Do you think you could cherry-pick the various fixes in "axi agent compilation fixes" to the commits that made the mistakes? Since we don't use squash merge in Mocha, this is a way to avoid putting Rupert's silly mistakes into the history :-)
Hey Rupert, Sure, I can merge the patches into your commits. This would also encompass the handshaking bugfix commit, for a total of two commits :) |
This is the first step towards a simple AXI agent. It will only have to handle the subset of AXI that is in use in the blocks in question (which work by translating to TLUL, so they aren't doing anything particularly exciting). In this commit, we're just defining interfaces for the five channels (which are AW, W, B, AR and R). Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
The axi_read_request_item and axi_read_data_item classes are intended to be randomised (when a sequence wishes to send either read requests or data responses). The axi_read_item class can be used by a monitor that sees a read request and then one or more responses. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
When the agent is representing an AXI Manager, this will be useful for the B and R channels. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
These drive write requests (AW) and write data (W) and also drive the write response channel (B). Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
For an example use-case, suppose you are reading with AR / R
transfers. You send an AR transfer with some ARID that will have a
burst with k beats. Now you want consume read data with that many (k)
R transfers using the some ID.
To do so:
- Run k axi_mgr_read_data_seq sequences, calling on_response() after
each finishes.
- (In parallel) call wait_for_response() k times.
The trick is that these sequences might respond with different IDs,
but that doesn't matter: the sequences are just actings as tokens to
allow *something* to come back.
| extern function new(string name = "axi_agent_cfg"); | ||
|
|
||
| // Set the identity/policy/width fields in one call. The interfaces are set separately by the BFM. | ||
| extern function void set_config(string inst_id = "axi_mgr", |
There was a problem hiding this comment.
I'm really not a fan of big lines of arguments with default values. As I wrote above, I think you only need to set is_active and enable_coverage. I'd suggest forcing the caller to pass both.
There was a problem hiding this comment.
I agree that the other fields were not needed - However I think that the inst_id carries value and should be kept. This field is rather useful for logging and debugging when there are multiple VIP instances. Even in our current integration, we have multiple monitors. I like the idea of being able to set a descriptive name for each instance that can show up on the logs.
As for the default values - I can remove these, although since its only 3 values, I dont think they hinder much.
Let me know what you prefer for both!
3863316 to
0d44df6
Compare
|
Hey @rswarbrick, In the meanwhile, I've folded the old compilation bugfixes commit into the respective commits that you made, so the commit history should be clear of bugs now. |
8f7d14d to
42c6a8d
Compare
This is a bare-bones agent for the five AXI interfaces. Note that there are no monitors, so the agent won't actually do anything in passive mode (yet). Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
To make it easier to "write address 123", there is an easy way to constrain the (single) sequence item in the sequence. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
The general sequence is axi_mgr_write_data_seq, but there is also a specialisation that sends exactly one transfer. This makes it easier to randomise a degenerate, length-one burst. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
To do so, we add a (pretty trivial) reg_adapter and a sequencer in a layered vseq that runs the resulting translated items. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>
7b39df5 to
17294bf
Compare
17294bf to
d9b35d7
Compare
d9b35d7 to
1ee3e13
Compare
This PR does a few things:
This was tested with the top level CVA6-based test cases.
Will close issue #168