For the RFSoC 2x2 which is a Zynq UltraScale+ RFSoC the PS block is: “Zynq UltraScale+ MPSoC”
See the base overlay for the 2x2 as an example.
The DMA IP will be similar.
The configuration of the PS block will be different - you have more options and more interfaces you can use. You can enable and connect the DMA to the HP in the FPD (Full Power Domain).
If this is your first time working with Zynq Ultrascale+ devices, you may want to try a beginner tutorial first.
HI ,
I am using the AXI-DMA on ZCU111 board with PYNQ. I am using the scatter gather mode and allocating number of buffer.
I am not able to allocate more that few MBs of total memory( 8192 buffers X 8192 bytes for each buff).
It there any restriction on how much memory can be allocated in a single Jyupter notebook?
Sorry for delay replying. The PYNQ buffers are contiguous. The amount of memory you can allocate will be determined by the amount of memory you have on the board, and the amount of that memory that can be allocated contiguously.
The FIFO in the design is intended as a loopback test. The DMA has AXI stream interfaces, so you need corresponding interfaces on your IP or an adapter to convert from AXI stream to your IP.
The simplest way to connect this would be to use a 256 bit wide DMA interface, and ignore the upper 256-136 = 120 bits. This would not be a very efficient use of memory but would be easy to connect.
You would need to add some logic to connect your IP to the AXI stream interface.
To do this more efficiently you need to figure out how you store the data in memory that you want to transfer to your IP. The memory is 32 bit, or the interface between the PS and PL is 64 bit. If you are going to transfer 1x 136 bits at a time you could read 32/64 bits sequentially via the DMA, “deserliaise” or reconstruct them into your 136 bit type (ignoring the upper bits).
For example, if you read 32 bits at a time, you need 5 x 4 bytes (160bits), and transfer these in parallel to your IP. In this case your IP would be running 5x slower than the DMA, as it takes at least 5 cycles to get the data that you transfer to your IP in one cycle. (If you use 64 bits, you would adjust the clocks accordingly.)
If you want to transfer a stream of 136 bits, again you need to determine how you store these in memory, transfer 32/64 bits at a time and deserialise into your 136 bit type. You could potentially store 136 bits contiguously (i.e. not byte aligned) and boost the efficiency of the memory transfer, but the logic to unpack your 136 bits will be more complicated.
I think you’ll need to add some handling of of the AXIS handshake (TREADY/TVALID) signals to your SPI RTL module. Maybe also TLAST which indicates the end of the DMA packet. I don’t think you will find any existing IP that you can simply plug in.
Yes, as @ggillett says, you need to do this yourself. AXI stream protocol has a handshake, so you need to decide how you want to manage this. You may be able to do something really simple like connect your data to the AXI stream data, if your “start” signal acts like a valid, you could add some logic for the handshake/valid.
There are some good tutorials on the internet. E.g. AXI stream:
This is for an AXI slave, and is a little dated, but may still be of use:
The DMA only supports the widths mentioned in the error. You could expand your signal using a “concat” block and concatenate zeros.
You would ignore the upper bits.
There will some inefficiency, but may be good enough for your use case.