AxiCrossBar with Standard Axi4 Interface in Briey #406
Comments
|
Hi, My guess is that for AXI it would be something like : axiCrossbar.addPipelining(myaxi)((from, to) => {
from.ar >> to.ar
from.r << to.r
}) ((from, to) => {
from.aw >> to.aw
from.w >> to.w
from.b << to.b
})And then you can add custom stages on the top |
|
Following your suggestion, I added the following code to Briey.scala: axiCrossbar.addPipelining(spi.io.axi)((crossbar, ctrl) => {
crossbar.ar >> ctrl.ar
crossbar.r << ctrl.r
})((crossbar, ctrl) => {
crossbar.aw >> ctrl.aw
crossbar.w >> ctrl.w
crossbar.b << ctrl.b
})This code does not have any syntax errors, but an error occurred when compiling and running Briey. The first error is: I analyzed that this error is caused by a mismatch between the address width of axiCrossbar.addSlaves(
ram.io.axi -> (0x80000000L, onChipRamSize),
spi.io.axi -> (0x20000000L, 32 kB),
apbBridge.io.axi -> (0xF0000000L, 1 MB)
)Where val spi = Axi4SpiCtrl(
addressWidth = 12,
dataWidth = 32,
idWidth = 2
)So, I changed the Anyway, after resolving the above error, I encountered a new problem, and the log shows: I don't quite understand how this issue arose. The following is part of the code I used when adding the Axi4 interface IP: val spi = Axi4SpiCtrl(
addressWidth = 20,
dataWidth = 32,
// byteCount = 32 kB,
idWidth = 2
)
axiCrossbar.addSlaves(
ram.io.axi -> (0x80000000L, onChipRamSize),
spi.io.axi -> (0x20000000L, 32 kB),
apbBridge.io.axi -> (0xF0000000L, 1 MB)
)
axiCrossbar.addConnections(
core.iBus -> List(ram.io.axi),
core.dBus -> List(ram.io.axi, apbBridge.io.axi),
spi.io.axi -> List(ram.io.axi)
)
axiCrossbar.addPipelining(spi.io.axi)((crossbar, ctrl) => {
crossbar.ar >> ctrl.ar
crossbar.r << ctrl.r
})((crossbar, ctrl) => {
crossbar.aw >> ctrl.aw
crossbar.w >> ctrl.w
crossbar.b << ctrl.b
})
object Axi4SpiCtrl {
def getAxiConfig(addressWidth: Int, dataWidth: Int, idWidth: Int) = Axi4Config(
addressWidth = addressWidth,
dataWidth = dataWidth,
idWidth = idWidth,
useLock = false,
useRegion = false,
useCache = false,
useProt = false,
useQos = false,
arUserWidth = 1,
bUserWidth = 1,
rUserWidth = 1,
wUserWidth = 1,
awUserWidth = 1
)
}
case class Axi4SpiCtrl (addressWidth: Int, dataWidth : Int, idWidth : Int, arwStage : Boolean = false) extends Component{
val axiConfig = Axi4SpiCtrl.getAxiConfig(addressWidth,dataWidth ,idWidth)
val io = new Bundle {
val axi = slave(Axi4(axiConfig))
}
/.../
} |
|
I realized my mistake was in the following code snippet: axiCrossbar.addConnections(
core.iBus -> List(ram.io.axi),
core.dBus -> List(ram.io.axi, apbBridge.io.axi),
spi.io.axi -> List(ram.io.axi)
)I wanted to control the SPI module through instructions from the iBus and dBus, so I should have directed the connections of iBus and dBus to the Axi4Spi. Therefore, I modified the code to: axiCrossbar.addConnections(
core.iBus -> List(ram.io.axi, spi.io.axi),
core.dBus -> List(ram.io.axi, apbBridge.io.axi, spi.io.axi)
)After the modification, the compilation passed, and it was able to output the file Briey.v. I think this modification should be correct. After studying the Axi4CrossbarFactory, I have some questions about the Axi4Shared interface it creates. In this interface, the write address channel and the read address channel of Axi4 share the IO. However, the standard Axi4 protocol should support simultaneous read and write operations on both the write address channel and the read address channel. It seems that the operation of Axi4Shared might prevent the write address channel and the read address channel from working simultaneously. Although this modification reduces the circuit area, it seems to come at the cost of communication speed. Additionally, I noticed that dBus is structured with an Axi4Shared interface. Will the Axi4CrossbarFactory automatically resolve the interconnection issues between the Axi4Shared and Axi4 interfaces? |
Depend what you mean by simultaneously.
I would say, address channel shouldn't be a bottleneck, unless you have a lot of single beat burst.
Yes it will bridge things |
|
Thanks for your reply! |
|
I found that |
Yes
It is because one master has the size signal, the interconnect want to propagate it down to every ends. |
|
My Axi4Spi controller IP currently does not support burst signal transmission. How can I inform the Axi4 Master in Briey that this slave does not support Burst signal transmission? |
|
What we would need is a bridge between AXI with burst -> axi without burst, which either respond with an error, either adapt things. The interconnect itself isn't handeling those kind of missmatch. |
|
Okay, now I am trying to find out how the issue arises through simulation. My program attempts to read a 32-bit value from address 0x20000000. The master sets the arvalid signal to 1 only on the first read attempt. When attempting to read the value from address 0x20000000 repeatedly, arvalid remains at 0. Since the slave does not receive the arvalid signal, it cannot determine whether the read address is correct and cannot update the state machine. This ultimately leads to the inability to assert the rvalid signal to tell the master that the read data is correct and to refresh the read value. I think that even when reading from the same address, the arvalid signal should be asserted high each time to indicate the start of a read to the slave, right? |
|
|
|
Hi,
Unless there is a burst requestwhich is the case here, see arlen. |
|
Thank you! I can understand what you said about why ARVALID wouldn't go high in Burst mode, but I don't know how to specifically set a memory region as an IORegion. What should I do? Here is some setup about my current memory map: |
|
it is specified here : But i would say, the simpler would just be to remap your spi.io.axi into the 0xF0100000L-0xFFFFFFFFL range |
|
After mapping the starting address of the memory region used by SPI to 0xF1000000, my problem seems to be resolved. I will conduct further verification. Thank you very much for your help! |
Hello, recently I have been wanting to add an SPI peripheral IP with a standard AXI structure to Briey's AxiCrossBar, which is written in SystemVerilog. I have noticed that the Axi4Shared interface is predominantly used in Briey's AxiCrossBar, and I believe the AxiCrossBar should be able to support the use of both the Axi4 standard interface and the Axi4Shared interface simultaneously.
The main issue I have encountered is that I do not know how to use the function addPipelining on an object of the Axi4 standard interface, and I have not found any relevant examples so far.
Regarding the AxiShared interface, I can see that the function is used as follows:
However, for the Axi4 type interface, I am not quite clear on how to wire it, so I am seeking some assistance and looking forward to your reply!
The text was updated successfully, but these errors were encountered: