problem in Creating a axi4 slave lite peripheral in vivado for Dual Port RAM

I have a Dual port RAM design with ports like

i created an axi slave peripheral in vivado and inlcuded above .v file, now the question is, how to instantiate this code with the standard axi4 interface signals, i tried like this below without using any user port declarations separately .

but im getting multidriven error with S_AXI_RDATA signal while optimizing the design. please correct me, if i am going wrong totally. otherwise rewrite those 6 lines for me, plz.

With what you have provided, the port mapping (although this is a VHDL term, I use it also for Verilog) looks ok!
Out port R data from mem is connected to axi_rdata.

Check if you have made some more connections for S_AXI_RDATA; thake is making it "multidriven".

btw - I hope you have the proper glue logic for i/f AXI and the dp_RAM signals!

yes, some more connection is also there like
assign S_AXI_RDATA = axi_rdata; somewhere in the middle.
what should i do now.

assign S_AXI_RDATA = axi_rdata; somewhere in the middle.

Click to expand...

That's the answer to your question.

How can you connect S_AXI_RDATA to mem_rdata when axi_rdata is already driving it!

Seems like you don't know your architecture/connections! Is this your own RTL code?

what should i do now.

Click to expand...

Revise your Verilog fundamentals. Then understand the architecture you want to build/implement.

Seems like axi_rdata is the Read-data bus which needs to be connected to the read data bus of the memory.
I don't know your architecture, so I can't provide you complete solutions. You need to figure out a way to do this without generating errors.

Actually i have a block design with a axi4 system containing micrblaze , uart , ddr3 where all these components are dragged from IP catalog. later i written a dpram which cant be connected directly to the existing block design unless it has got axi4 interface by some means.
so, i am trying to acheive a axi interface to the dpram.

previosuly , i did a full adder with the design (assign sum=a+b);
a port mapped to slv_reg0;
b ...... to slv_reg1; which worked fine. but this time, im dropped in some advanced RTL modification inside this axi4 slave template.

i'll try, if u had something plz share with me. thank you.

later i written a dpram which cant be connected directly to the existing block design unless it has got axi4 interface by some means. so, i am trying to acheive a axi interface to the dpram.

Click to expand...

Hence I had asked in #2 : btw - I hope you have the proper glue logic for i/f AXI and the dp_RAM signals!

Yes you have to write the bus conversion logic properly for interfacing. AXI <--> RAM_module

i'll try, if u had something plz share with me.

Click to expand...

I am afraid that is custom work and needs to be written from scratch.

dpaul said:

I am afraid that is custom work and needs to be written from scratch.

Click to expand...

Hmmm, I've got a Vivado block design with a Block Memory Generator component and the AXI BRAM Controller in it. Nothing custom about it, they are both part of the Add IP dialog options.

i think i found what iam lacking. so, to master the concept of bus conversion logic. can u provide some web materials /references.

thank you.

- - - Updated - - -

ads-ee said:

Hmmm, I've got a Vivado block design with a Block Memory Generator component and the AXI BRAM Controller in it. Nothing custom about it, they are both part of the Add IP dialog options.

Click to expand...

I am not talking about the IP's available in IP catalog.

If you are connecting a block RAM to an AXI bus you can look at the code for the AXI BRAM controller and it has all the extra glue logic you need to implement AXI with a BRAM. Sure you can make all of the custom code you want, but I just thought I would mention that there is a possible reference to doing this. Just hooking the BRAM directly up to the AXI signals isn't going to work due to the protocol between the BRAM and the AXI4 being radically different in timing.

I don't know any references or howtos on bus conversion logic, I've always just done it based on the specifications for the two different buses.

anilineda said:

i think i found what iam lacking. so, to master the concept of bus conversion logic. can u provide some web materials /references.

thank you.

- - - Updated - - -



I am not talking about the IP's available in IP catalog.

Click to expand...

You basically need to read the relevant specs and see what can be done to match the assumptions/requirements of each.

AXI is mildly annoying -- to the point that even some "professional" cores ignore the parts they don't like. AXI has the following common gotchas:
1.) As an AXI master, you CANNOT wait for the slave to become ready. Instead you must assert that you want something and wait for the slave to complete the request.
2.) The data and address channels can be initiated and acknowledged independently.
3.) This isn't a fifo interface -- something can become busy at any time.

These are three important examples of small corner cases in AXI that do affect developers. For reasons like this, AXI can be difficult to get right. It also leads to the almost-axi interfaces that exist in some cores.

Is there a reason why you don't want to use the existing AXI to BRAM interface from Xilinx?

(there is also an issue of addressing when used with a CPU as a memory mapped abstraction will usually assume byte addressable, while HW assumes word-addressable unless otherwise required)