AXI4 Interface and Functional Modeling #159
Conversation
…s on agents. Tests are failing but build.
Implementing of burst wrap and partial prot support.
| this.hasWrite = true, | ||
| this.rIntf, | ||
| this.wIntf, | ||
| }) : assert( |
There was a problem hiding this comment.
asserts only execute in tests and debug mode -- should these be exceptions?
There was a problem hiding this comment.
Yeah I guess? Can we throw exceptions in the initialization list like the assertions now? What's the syntax?
There was a problem hiding this comment.
you can't throw exceptions there, but you can do checks within the body of the constructor and throw an exception if they fail (a little more verbose/clunky, but probably appropriate for this case)
| final Axi4SystemInterface sIntf; | ||
|
|
||
| /// Channels that the agent can send requests on. | ||
| final List<Axi4Channel> channels; |
There was a problem hiding this comment.
The spec calls a "channel" something else?
https://developer.arm.com/documentation/102202/0300/Channel-signals
Conceptually, is there a reason why we should have a list of channels rather than just a list of read interfaces and a list of write interfaces provided to the main agent? With read and write agents created per read/write interface? That would result in collection of the corresponding sequencer, driver, and monitor on a per-interface basis without the need to keep track of a channel index across multiple independent Lists.
There was a problem hiding this comment.
So the notion of a "channel" as I've defined it has a few implications. Essentially, for certain actions like locking we need to keep track of which "main" performed the action. This is what I use the notion of a channel for. It is also a nice logical distinction/categorization of the interfaces to understand "who" they are associated with.
That being said, sounds like we might need a new for "channel"? I just find this metadata to be useful to help reason about the system/network.
There was a problem hiding this comment.
Ah I see, I didn't realize that there was a relationship between a "pair" of read and write agents. Does it not make sense to still group, for example, a write sequencer, write driver, and write monitor into one "write agent", and similar for read?
| final LogicValue end; | ||
|
|
||
| /// Secure region. | ||
| final bool isSecure; |
There was a problem hiding this comment.
do we need to do any extra testing for secure and privileged?
There was a problem hiding this comment.
Yeah we absolutely do. I think there is some coverage through sheer randomness but we will want directed tests at some point.
Description & Motivation
AXI4 is a common protocol and thus adding a ROHD implementation for its interface and some of its behavior. The structure is very similar to what was done for APB4.
Related Issue(s)
N/A
Testing
Unit tests were created very similar to the unit tests for APB4.
Backwards-compatibility
Fully backwards compatible.
Documentation
Documentation is forthcoming.