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!
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.
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.
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.
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.
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)