AXI4 Interface and Functional Modeling #159
Conversation
| final Axi4SystemInterface sIntf; | ||
|
|
||
| /// AXI4 Read Interface. | ||
| final Axi4ReadInterface rIntf; |
There was a problem hiding this comment.
Is there always a pair of 1 write and 1 read interface in AXI? Are there cases where someone might have variable numbers of both/either?
There was a problem hiding this comment.
That's actually a good question. I definitely know of instances where the block has a vectorized number of AXI interfaces. I can't think of an instance where the number of read instances doesn't match the number of write instances but maybe the spec further clarifies this?
Say we just support a vectorized number. Would we just instantiate that many drivers and sequencers?
There was a problem hiding this comment.
Yes, you could perhaps group things (e.g. a "write agent" has a driver and sequencer bundled together). I think a configurable number makes a lot of sense independently for reads and writes unless the spec specifically calls out that they must be the same number.
| this.dropDelayCycles = 30, | ||
| }) : super(name, parent) { | ||
| sequencer = Sequencer<Axi4RequestPacket>('sequencer', this); | ||
|
|
There was a problem hiding this comment.
should the main agent come with a monitor included?
There was a problem hiding this comment.
I guess yeah it probably should, right? I was just copying what APB did here (it also doesn't have a monitor).
There was a problem hiding this comment.
sorry for the bad example haha, i think it makes sense probably to have a monitor included
| /// A driver for the [Axi4ReadInterface] and [Axi4WriteInterface] interfaces. | ||
| /// | ||
| /// Driving from the perspective of the Main agent. | ||
| class Axi4MainDriver extends PendingClockedDriver<Axi4RequestPacket> { |
There was a problem hiding this comment.
should this driver be split into two, one for read and one for write?
There was a problem hiding this comment.
I guess it could? Doesn't seem like the logic is too complicated though for a single driver to handle both reads and writes. Maybe there's another benefit though?
There was a problem hiding this comment.
If you have independent numbers of write and read interfaces, then you'd want them split apart
| /// A model for the subordinate side of | ||
| /// an [Axi4ReadInterface] and [Axi4WriteInterface]. | ||
| class Axi4SubordinateAgent extends Agent { | ||
| /// The system interface. |
There was a problem hiding this comment.
should this subordinate be split into an agent, monitor, and two subordinate drivers?
There was a problem hiding this comment.
This change would follow from our decision to split out the read and write drivers presumably.
| : LogicValue.ofInt(Axi4RespField.okay.value, wIntf.bResp!.width)); | ||
| wIntf.bUser?.put(0); // don't support user field for now | ||
|
|
||
| // TODO: how to deal with delays?? |
There was a problem hiding this comment.
reminder to follow up on any remaining TODOs
There was a problem hiding this comment.
There are two (semi) big ones that I want to discuss regarding delays between request/response and handling of the ready signal (i.e., backpressure).
| import 'package:rohd_vf/rohd_vf.dart'; | ||
|
|
||
| /// A monitor for [Axi4ReadInterface]s and [Axi4WriteInterface]s. | ||
| class Axi4Monitor extends Monitor<Axi4RequestPacket> { |
There was a problem hiding this comment.
split monitor into a read and write monitor?
There was a problem hiding this comment.
I guess it could? Doesn't seem like the logic is too complicated though for a single monitor to handle both reads and writes. Maybe there's another benefit though?
There was a problem hiding this comment.
same consideration as above -- if you have different numbers of read and write interfaces
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.