Sorry, you need to enable JavaScript to visit this website.

PS/PL BRAM share

Zedboard forums is currently read-only while it under goes maintenance.

Unsolved
34 posts / 0 new
PS/PL BRAM share

I have a Linux/FreeRTOS AMP on the PS cores. I am trying to benchmark a CPIW created custom accelerator. What I have in mind is to use BRAM to provide data to the user logic submodule computation.

I reference AR #50826 ..CDMA transfers from block RAM to OCM. I conceptualize data arriving via ethernet placed in OCM by a linux App (or some custom peripheral). Then the data is moved from OCM to BRAM for use by the custom IP in the PL.

From the AR, with a AXI BRAM controller and AXI CDMA, I can move data to/from a BRAM. All this is designed in XPS.

Now I want to use the other unconnected BRAM port to read/write data to/from the user logic. I assume that I have to add the BRAM interface as USER PORTS in user_logic.v and proliferate up to system hdl and down to define the PORT B interface in the BRAM module.

Is there an cleaner way to do this? The BRAM controller to BRAM interface in XPS was easy due to the innate BRAM connection. Since my custom peripheral (computational accelerator) has no such native BRAM interface, is the only way to do it within the HDL?

AXI4 Memory Mapped Based Interface

Would using the AXI4 MMAP interface for the custom accelerator provide the functionality that I am looking for? On the surface, the documentation seems to indicate its use more for data peripherals than for parallel number-crunching, but actually i have not seen reference designs.

XPS elements

added to my ip .mpd file (from axi_bram_ctrl .mpd):

BUS_INTERFACE BUS = BRAM_PORTB, BUS_STD = XIL_BRAM, BUS_TYPE = INITIATOR

and
PORT BRAM_Rst_B = BRAM_Rst, DIR = O, BUS = BRAM_PORTB
PORT BRAM_Clk_B = BRAM_Clk, DIR = O, BUS = BRAM_PORTB
PORT BRAM_En_B = BRAM_En, DIR = O, BUS = BRAM_PORTB
PORT BRAM_WEN_B = BRAM_WEN, DIR = O, BUS = BRAM_PORTB, VEC = 3:0, ENDIAN = LITTLE
PORT BRAM_Addr_B = BRAM_Addr, DIR = O, BUS = BRAM_PORTB, VEC = [(C_S_AXI_ADDR_WIDTH - 1) : 0], ENDIAN = LITTLE
PORT BRAM_Dout_B = BRAM_Dout, DIR = O, BUS = BRAM_PORTB, VEC = 31:0, ENDIAN = LITTLE
PORT BRAM_Din_B = BRAM_Din, DIR = I, BUS = BRAM_PORTB, VEC = 31:0, ENDIAN = LITTLE

now it looks pretty in XPS.

now to make sure my HDL matches!

sticken
Junior(0)
Did you modified something in

Did you modified something in your "user_logic.vhd"? How can you connect those signals to vhdl signals declared inside the vhdl code of your peripheral?

Thank you,
sticken

Matching .vhd and user_logic.v

Hurray! The HDL (from PlanAhead) is synthesizable.
Getting it right in the pcore put it right automatically, and the XPS Bus Interface tab looks clean.

"We don't need no stinkin' XPS license."

So now, do the DMA from FreeRTOS, and then roll the BRAM data to my submodule ports.
Getting there. Can I do it?

sticken
Junior(0)
Need help on this topic

Hello james,

I'm working on this issue. I instantiated a BRAM controller and a BRAM in my XPS project, but when I push the "Generate Addresses" button, then the controller remains under the "Unmapped addresses" list. It gets an address, but it seems that is unmapped. I followed UG873 cap.6 to instantiate a CDMA peripheral. Could you give me any hints to solve my problem?

Thank you,
sticken

my bram_ctrl @ 0x80000000

Hi,

I got the same result -- the bram_ctrl remained under unmapped but received an address. This address is used to access the BRAM from the CDMA. I was able to use this address to execute DMA transfers to and from BRAM to and from high OCM.
did you try to complete the SDK app and attempt a DMA transfer?
In another vein, for my attempted accelerator, I used the ACP to move datasets into BRAM instantiated in XPS. But then I got bogged down when trying to access the BRAM from within my custom IP user logic. The resultant dual bus AXI and BRAM interface module is giving me problems where the user_logic modules are trimmed in synthesis due to the way the BRAM access is coded in HDL. I needed to add the BRAM interface to my IP's .mpd. XST is somehow setting the BRAM ports to constant values and trimming the module.
So I changed to the AXI burst mode in the CIPW and now am working with that mode of transferring the dataset. This creates inferrred BRAM within the IP user_logic, which you can use to transfer data sets and results. However, I don't think the burst mode is supported in AXI_Lite, so I think you need to convert your XPS design to AXI from AXI_lite.
I still work on both versions though. I can't see why you can't access the BRAM from your IP and am reading the 400+ pages of HDL for the AXI_BRAM_CTRL Xilinx IP to get insights into how to have AXI and BRAM bus interfaces in coexistence.

hope this helps.

i think avnet and/or xilinx neds to weigh in on this subject with reference designs, UG etc.

liucheng
Junior(0)
I am also trying to use PL as

I am also trying to use PL as an accelerator and need a shared buffer for communication between PL and PS. It seems that the AXI_BRAM_CTRL might be helpful. According to the posts "Can the AXI BRAM CONTROLLER ports be made external", it should be able to have a BRAM port exposed to user logic. However, I tried all the possible configurations, and now I am pretty sure there is no way I can make any of the BRAM port external at least on XPS 14.4. I am not sure if it a bug or something. Anyway, I also tried another way by adding an AXI4 peripheral with the XPS wizard. By default, I got an AXI4 peripheral supporting burst transfer. The default configuration of the peripheral is actually a RAM block implemented in synthesizable HDL code. It is really cool, because it allows me to configure the BRAM whatever I want. While the problem is that it does not support AXI burst and I am not familiar with AXI4 protocol. So I am writing to see if I missed something. I guess this is really a basic communication scheme for PL and PS. Is there any easier way to implement a dual port BRAM for the PL-PS communication? If not, I may have to go back to the lengthy AXI4 specification.

vhorsev
Junior(0)
I want to get your project

I want to know how you can solve the problem,can you tell me the way and give me the source code you write,thank you

sticken
Junior(0)
Finally I managed..

Finally I managed to perform a DMA transfer from DDR to BRAM and from BRAM to DDR. Unfortunately when I read value wrote back in the DDR I face a strange behaviour. In practice some values don't make any sense to me. The CDMA transfers number from 0 to 1023 (so 1024 integers, each of them 32 bit wide). Ok, when I print the numbers stored in the destination memory I see that some values don't belong to numbers from 0 to 1023.

Example:

Value: 892
Value: 893
Value: 894
Value: 895
Value: -476021416
Value: 27279365
.
.
.
Value: 912
Value: 913
Value: 914

As you can see the is an interval of numbers that are completely wrong. Strange behvior: those intervals can be more than one and I noted that are made by 8, 16 or 32 numbers..

Any hint would be really appreciated!!

sticken

DDR transfer

My design only used OCM and not DDR. Sorry and good luck finding it.
Probably an issue specific to using DDR with CDMA. If I find the answer digging into the TRM, I will post it here.

sticken
Junior(0)
Ok, thank you

Ok thank you very much!
Some more questions:
1) What should I do if I want to use OCM? Should I use ACP Instead HP?

2) What kind of data do you transfer? maybe my problem is related to data format

sticken
Junior(0)
P.S: I don't see this problem

P.S: I don't see this problem when moving data to/from different DDR locations. Could be a problem related to BRAM controller and/or BRAM?

sticken
Junior(0)
Forget my last post. I

Forget my last post. I noticed that this problem also occurs when I try to transfer data from DDR to DRR. In particular I noticed that a second or third transfer has this problem. Between different transfers I correctly rset the CDMA core and re-program it with different addresses etc. Do I miss something? I can't understand this strange behavior..Can I perform different transfers by reusing the same core? I hope so..

Thank you very much,
sticken

sticken
Junior(0)
Yeah

Thank you for your quick answer. You're right, it seems that DMA transfer from DDR to BRAM ends succesfully: status register contains correct value. But I can't understand one thing. BRAM controller is automatically connected to a BRAM in PL? I tried to perform another transfer, from BRAM controller to DDR in order to check whether the values are correct, but they're not..maybe I missed something..

Thank you again,
sticken

prince_8889
Junior(0)
Did u solve the issue regarding bram controller ??

Hii All,

I can actually write data to BRAM and recieve the data correctly in DDR. But not the opposite I have checked using chipscope then I realized that the problem is with BRAM CONTROLLER.

Did YOU solve this issue??

prince_8889
Junior(0)
Disabling cache is important

There might be two problems in this case

1. the cache is not disabled

2. It might be a problem of addressing from Pl side

prince_8889
Junior(0)
I cant read from ddr via BRAM(BRAM IS THE PROBLEM)

Hii All,

I can actually write data to BRAM and recieve the data correctly in DDR. But not the opposite I have checked using chipscope then I realized that the problem is with BRAM.

Did anyone solve this issue??

BRAM second port externalized

I have seen your design on the forum topic "Basic question: Axi single port BRAM READ OPERATION." I see that you make the second BRAM port external under XPS. If you make the ports external how do you connect them to your custom IP within system.xmp? I see external ports for the Zynq pins that connect to DDR memory, etc.
I am trying to add a BRAM port interface directly to my custom IP as user defined ports and access the second port of BRAM that way.
That old Avnet Silica video did it the same way as you do, but that was for a microblaze system which is a little different the Zynq.
Yes I am still very interested in getting this working properly.

prince_8889
Junior(0)
I dont connect to custom IP

Hello James,
I connect the external pins to my vhdl modules not to any custom IP. I then send data through these pins to bram from my VHDL modules.

It works fine for me.
But I still dont understand why I cannot read data out from these pins.

please explain port connections

hi pruthvi,
so your peripheral is extraneous to the zynq .xmp design? and you have some hierarchy above the top hdl stub?
you pass data from your module "through the pin" to the xps instantiated bram, which you are able to verify? how do you verify? do you have an axi bram controller with which to read the data out of the bram? same as used for dma? or do you use chipscope to verify data?
but when you dma in the other direction the data does not make it back to ddr?
I am sorry if I seem not to understand. I thought external pins were to take data off the zynq to other chips when you design for zynq. like clock and ddr and fmc etc. you have multiple design sources but somehow there are ports back to the zynq fpga fabric?

I have a question today that I am going to investigate: can you dma to a custom IP set up as a burst capable high throughput memory mapped device? are the memory mapped buffers guaranteed to be inferred bram. where can I see the axi bram controller logic to access the bram? after synthesis? does the xps defined addressing determine the size of the buffers? the generated user_logic module does not show this. do I just change the buffer sizes to insure the inferred bram size?
this is a very important part of mastering this technology for my colleague Charles Babbage. I must find out ASAP!

prince_8889
Junior(0)
HOW to VERIFY DATA FROM BRAM TO DDR

Hi james,

It is very simple generate dummy data in FPGA(ex: counter or hardwired number - 32 bit) and transfer thru bram to ddr and print the ddr memory range.
if you recieve the same number then your transfer works.

verification simplified

okay, I see. known data generated in an FPGA module. And this is where your design fails. conversely you are seeing the data in your FPGA module. How, chipscope or another scheme? certainly it wouldn't be suitable to read the data in that direction from DDR memory!
I think I am seeing successful use of CDMA to move data from DDR to an XPS instantiated BRAM via an AXI BRAM Controller and get the data back again in DDR. Like you I am moving a known data buffer (8KB) to the BRAM, but moving it back from an offset (4KB offset 80B) and I am seeing the expected values back in DDR.
Not exactly a scan chain of the "Hollerith" values I am moving to the FPGA fabric, but as always a piecewise refinement gaining functionality...or not!

prince_8889
Junior(0)
VERIFYING DATA IN SDK CONSOLE

K u seem to be a bit confused

my transfer starts from FPGA to DDR this way works perfectly.

vhdl MODULE()---> BRAM EXTERNAL PORTS----> BRAM CONTROLLER---> CDMA---> AXI HP PORTS---> DDR RAM

I PRINT THE DATA RECIEVED IN DDR IN XILINX SDK CONSOLE this is perfect.

Now the opposite direction fails(DDR to VHDL): BUT WHEN i USE CHIPSCOPE i CAN SEE DATA IN SLAVE PORT OF BRAM CONTROLLER BUT COULDNT RECIEVE THE DATA

is it clear now??

chipscope verification failure

vhdl MODULE()---> BRAM EXTERNAL PORTS----> BRAM CONTROLLER---> CDMA---> AXI HP PORTS---> DDR RAM

no I did understand. perhaps I did not state clearly enough. in your arrangement, you can't get data from DDR to your HDL module.
it is interesting that it appears the data is making it to the BRAM through the external ports, making use of the second BRAM port; and further the BRAM can access the BRAM data and put it on the AXI bus via the CDMA.
Without the use of the second BRAM port I can write to BRAM using CDMA and the BRAM controller. Then I can DMA the data in BRAM back to DDR. I am curious -- have you tried doing the reverse DMA following the failure to reach your HDL module? Is the data as sent from DDR actually in the BRAM? indicating a failure of the read from the second BRAM port thru the external ports? you seem to be saying you don't think the data ever gets into the BRAM thru CDMA from DDR. or is it something about the external ports being used to get the data -- I don't know. what do you think?
I am trying a more direct approach with user added ports of the a custom peripheral which attempt to link to the second BRAM port directly under the .xmp system. there is something wrong and i'm also trying to solve this. you at least are able to access the BRAM from your HDL module. I give you credit for that; I can see BRAM data back in DDR, but need to access it in my FPGA module.
That was my initial question concerning our obvious difference. Why does the BRAM second port need to be external? It's okay if you don't care to address this -- I will persevere in any case.

good luck, pruthvi. I am sure you will solve this by your own means.

prince_8889
Junior(0)
I get data back from ddr to BRAM but..

Hello James,
I can see data in slave axi port of bram controller using chipscope but cannot read data from port b of bram tried many things but dont no whats really happening

are we subtley miscontructed or in fog of undocumented?

thank you for replying, pruthvi.
I think we have encountered similar problems. which of either of us has a correctable mistake in design? likewise which could benefit from a reference design exhibiting this facet of the very basic generic function using PL to accelerate computation. I can't help but think that we are lacking some community at-large provisions from avnet and Xilinx.
please feel free to share your progress; I will continue to post to this thread. I just hope our exhibits are not deemed obtuse by the zedboard staff.
cheers, pruthvi!

sincerely,
james

DMA to share BRAM PS/PL

Hi Pruthvi,

I have been able to use the ACP to DMA between DDR and an XPS instantiated BRAM using an AXI BRAM controller, verifying the data with reverse DMA. My AXI slave CIP uses the other BRAM port to access the data for my user logic, and then I DMA it back to DDR, seeing the results of user logic manipulation.
I also used a CIP AXI master burst peripheral, but I didn't see a difference between ACP and HP0. I DID disable cache for each.

prince_8889
Junior(0)
IS IT DMA OR CDMA??

Hello James,

Are you using DMA or cdma. Its better if u post your bus interfaces tab from edk here.

CDMA

Like AR #50826. See above for how I added BRAM port to my CIP.

prince_8889
Junior(0)
K got it

I tried this it worked for me, What is strong feel is a custom IP peripheral with AXI bus system should work.
I have seen many in xilinx forums successful with this approach. I think you are also working on the same lines.

Regards
Pruthvi

felicitations!

thank you for your kind words. I think that rather than cannibalize the BRAM bus interface from the axi_bram_ctrl core .mpd, it should be available to choose in XPS.
I wonder if this is something Xilinx would entertain.
the CIP wizard MMAP burst achieves similar results, but then you have to get the data out of the srl_fifo module. I think it does not give the option of using BRAM instead like another core like axi_datamover_fifo. there may arise a design that needs the LUTs/regs more than all the BRAM in the fabric.
cheers!

xilin
Junior(0)
Option: Slave Single Port BRAM

Even if you want to use a dual port bram you have to make sure that:

"Slave Single Port BRAM" under your axi_bram_ctrl (System tab under AXI) is checked.

Otherwise "Port A of the BRAM module is designated as
the write port, while Port B of the BRAM module is designated as the read port" (see http://www.xilinx.com/support/documentation/ip_documentation/axi_bram_ct... under BRAM Interface).
Your bram_block still has two ports and you can connect your custom ip to Port B.

Tilottoma07
Junior(0)
Picozed SDK FMC Carrier Card

Hello, I am using Picozed FMC carrier card board. I have a project of using shared memory in Zynq processor between PS & PL.
Can anyone help me how i can do that ? Is there any OCM or BRAM which they can share to communicate?
Thanks in advance