Arbitration Behaviour of axixbar

[zipcpu]

Arbitration Behaviour of axixbar

[ZipCPU]

Let's see what I can answer here:

When one AXI master is waiting for the read response(of its read request) [will the other] AXI master's ARREADY and AWREADY signals [get] de-asserted?

Not quite. The read channel doesn't impact write arbitration. Hence, while one master is interacting with the read channel, another master might be interacting with the write channel. Second, each channel has a skidbuffer on entry. As a result, all channels hold AxREADY high until they have accepted a single request. Once that request has been entered, AxREADY will typically drop until that channel receives arbitration.

[Will] ARREADY/AWREADY [be] de-asserted [until] ARVALID/AWVALID [are] asserted?

Not at all. Because of the skid buffers, the AxREADY signals are held high. If the crossbar isn't ready to accept a beat on the same cycle, it will get buffered until it can be internally forwarded.

Or it's the AXI masters' responsibility to not issue requests at the same time?

The AXI master has only one responsibility: follow the AXI specification. No other requirements are made upon the various masters connected to the crossbar.

Dan

[predator2k]

I see. So the core idea is that all masters have their own skid buffer to save the request, and AxREADY mostly depends on whether the skid buffer is full or not. Am I right?

[ZipCPU]

Exactly.

[predator2k]

OK. Thank you for your reply & good work.