cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
MuzamilFarid
Adventurer
Adventurer
1,048 Views
Registered: ‎04-12-2020

AXI master read and write in RTL

Jump to solution

Hello every one

my question is how can an AXI master perform read and write operations on BRAM or DDR3 in RTL?

can some one please share an example as how that can be done in RTL, as which signals are involved and where to connect those signals.

As per my understanding AXI master has 5 channels which contains address and data read/write signals, Are these signals involved in performing read/write operations?

Vivado generates an Auto code for AXI master peripheral, can i use this auto generated code for read/write transactions on RAM? or if this code needs to be edited how exactly that can be done? 

I will greatly appreciate some example or tutorial regarding my query, I know its a pretty basic query so i hope some one must have some example to share.

thanks

0 Kudos
1 Solution

Accepted Solutions
dgisselq
Scholar
Scholar
933 Views
Registered: ‎05-21-2015

@MuzamilFarid,


@MuzamilFarid wrote:

@dgisselq 

thanks again for your reply, greatly appreciate it.

i will explain my task in full detail here.

I have to develop a IP core that has stream interface on one end where streaming data is coming in and i have to write this streaming data to DDR3 using AXI DMA.

You can find an example of such a core here.  Feel free to modify it as the license allows.


I have to configure AXI DMA using this IP core as i dont want to involve in PS in the whole process. AXI DMA has S_AXI_LITE port through which it can be configured but i have no clue as how that can be done from Custom developed IP core. 
  1. The example I recommended in my prior response, citing the ZipCPU blog, discusses how to build an AXI master.  It's generic enough that you could use it for both AXI or AXI-lite--just don't set the AXI only pins and you'll be fine.
  2. Xilinx's example, generated from their IP core generator, would also work nicely for scripting an AXI-lite transaction.
  3. You could also tear the AXI-lite interface out of the open source core listed above and so script your interaction that way.

For a moment i want to keep things simple, I dont want to involve AXI DMA, I just want to generate some data in my custom IP and then write this data to some address locations in DDR3. As per my understanding i need an AXI master interface which will be able to perform read/write transactions to DDR3 directly. I just want to see in an example or tutorial some where how can that be done and how AXI signals can be connected . I hope my query is clear.


For me, simple is interacting with a design from an external command over an external interface without involving the complexity of an on-board CPU (yet).  I like to call such an interface a "debugging bus", whereby you issue AXI requests (commands) to your design, and then query it to see how it is working.  While I typically use Wishbone for this purpose, there are slides in the ZipCPU intermediate tutorial pages discussing how to do this with AXI.  There's also a very simple AXI master you can use for this purpose as well--all driven from an external serial port for when you are ready to issue those commands.  That way you replace the processing side "computer", and so you don't have to include that complexity in your work.

My typical test design, which I use when I'm ready for hardware development, would include a 1) UART to Wishbone (you could use AXI) bridge, 2) driven by a TCP/IP to serial bridge, 3) driven from a simple host interface, commanding a bus that includes a 4) internal logic scope to capture what's going on as well as a 5) the device I am testing.  Were I working with the AXI stream protocol as well, I'd probably also use 5) an AXI-lite to AXI stream converter, such as I just recently blogged about, to generate stream commands--that way I could control example what was going into the stream and verify that what was written to memory matched exactly.  At a minimum, I would require of any development approach like this that I be able to 6) simulate the entire design from the first clock tick to the end of my interest, and be able to therefore generate a 7) VCD trace showing what's working and what isn't allowing me to drill back down through the design to see what went wrong (if anything).  That would all be done before I ever actually touched hardware.

This is much better for debugging than just running a design and looking for a blinking light (the most painful way to debug) since you can then also query the design (via first the complete trace, and then later via the internal logic scope) to see what went right or wrong along the way.  AXI makes this a bit more difficult than Wishbone, simply because there's no bus abort capability in AXI.  One broken component will kill the rest of the design.  That's why it's so important to formally verify AXI components.

If you are just starting out, then I'd try to write an AXI-lite master rather than an AXI one.  It's much easier.  (Calculating burst sizes can be a real challenge when using AXI, and those AXI ID's can be a real pain to work with when reading.)

At this point, you should now have several examples to work with.  It's time to start building and making mistakes that you can then learn from.  Were this my project, I'd start with SymbiYosys and the open source formal properties for AXI-lite.  (Use the master properties faxil_master.v, not the slave properties--they both exist in the same repository I've linked you to before.)  If you can prove that your design meets those properties while still doing (whatever it needs to do), then you'll be there.

Dan

View solution in original post

0 Kudos
4 Replies
dgisselq
Scholar
Scholar
1,023 Views
Registered: ‎05-21-2015

@MuzamilFarid,

The difficult part about building a generic example AXI master is that where the master gets its transactional commands from, in order to issue  them over the AXI bus, changes from one application to the next.  Which example makes the most sense for your application?

As we discussed in your last forum query, Xilinx's example designs create a design that writes to memory and then reads the results back some time later.  While this makes a fairly decent design, very few other designs will require writing to memory and then reading the same addresses back later.

I recently blogged about how to build an AXI master.  In that case, the AXI master is driven from bus commands generated by an external Wishbone bus and so the AXI master core acts purely as a bridge from one domain to another.  It makes a great generic AXI master example to look at save ... if you aren't bridging from one protocol to another then it might feel rather irrelevant to your needs.

If that doesn't work for you, you can find roughly another seven or so examples of AXI masters in this open source github repository.  These examples range from unattented memory copies (DMAs) from memory to streams, streams to memory, or even memory to memory, to AXI firewalls, bus simplifiers, and bridges like I blogged about above.  Lord willing, I'll be adding a video frame buffer example to the set soon enough as well.

I guess the answer comes down to, what do you want to do with the AXI bus?  That will dictate a lot of how you go about interacting with it.

Dan

0 Kudos
MuzamilFarid
Adventurer
Adventurer
977 Views
Registered: ‎04-12-2020

@dgisselq 

thanks again for your reply, greatly appreciate it.

i will explain my task in full detail here.

I have to develop a IP core that has stream interface on one end where streaming data is coming in and i have to write this streaming data to DDR3 using AXI DMA.

I have to configure AXI DMA using this IP core as i dont want to involve in PS in the whole process. AXI DMA has S_AXI_LITE port through which it can be configured but i have no clue as how that can be done from Custom developed IP core. 

For a moment i want to keep things simple, I dont want to involve AXI DMA, I just want to generate some data in my custom IP and then write this data to some address locations in DDR3. As per my understanding i need an AXI master interface which will be able to perform read/write transactions to DDR3 directly. I just want to see in an example or tutorial some where how can that be done and how AXI signals can be connected . I hope my query is clear.

0 Kudos
dgisselq
Scholar
Scholar
934 Views
Registered: ‎05-21-2015

@MuzamilFarid,


@MuzamilFarid wrote:

@dgisselq 

thanks again for your reply, greatly appreciate it.

i will explain my task in full detail here.

I have to develop a IP core that has stream interface on one end where streaming data is coming in and i have to write this streaming data to DDR3 using AXI DMA.

You can find an example of such a core here.  Feel free to modify it as the license allows.


I have to configure AXI DMA using this IP core as i dont want to involve in PS in the whole process. AXI DMA has S_AXI_LITE port through which it can be configured but i have no clue as how that can be done from Custom developed IP core. 
  1. The example I recommended in my prior response, citing the ZipCPU blog, discusses how to build an AXI master.  It's generic enough that you could use it for both AXI or AXI-lite--just don't set the AXI only pins and you'll be fine.
  2. Xilinx's example, generated from their IP core generator, would also work nicely for scripting an AXI-lite transaction.
  3. You could also tear the AXI-lite interface out of the open source core listed above and so script your interaction that way.

For a moment i want to keep things simple, I dont want to involve AXI DMA, I just want to generate some data in my custom IP and then write this data to some address locations in DDR3. As per my understanding i need an AXI master interface which will be able to perform read/write transactions to DDR3 directly. I just want to see in an example or tutorial some where how can that be done and how AXI signals can be connected . I hope my query is clear.


For me, simple is interacting with a design from an external command over an external interface without involving the complexity of an on-board CPU (yet).  I like to call such an interface a "debugging bus", whereby you issue AXI requests (commands) to your design, and then query it to see how it is working.  While I typically use Wishbone for this purpose, there are slides in the ZipCPU intermediate tutorial pages discussing how to do this with AXI.  There's also a very simple AXI master you can use for this purpose as well--all driven from an external serial port for when you are ready to issue those commands.  That way you replace the processing side "computer", and so you don't have to include that complexity in your work.

My typical test design, which I use when I'm ready for hardware development, would include a 1) UART to Wishbone (you could use AXI) bridge, 2) driven by a TCP/IP to serial bridge, 3) driven from a simple host interface, commanding a bus that includes a 4) internal logic scope to capture what's going on as well as a 5) the device I am testing.  Were I working with the AXI stream protocol as well, I'd probably also use 5) an AXI-lite to AXI stream converter, such as I just recently blogged about, to generate stream commands--that way I could control example what was going into the stream and verify that what was written to memory matched exactly.  At a minimum, I would require of any development approach like this that I be able to 6) simulate the entire design from the first clock tick to the end of my interest, and be able to therefore generate a 7) VCD trace showing what's working and what isn't allowing me to drill back down through the design to see what went wrong (if anything).  That would all be done before I ever actually touched hardware.

This is much better for debugging than just running a design and looking for a blinking light (the most painful way to debug) since you can then also query the design (via first the complete trace, and then later via the internal logic scope) to see what went right or wrong along the way.  AXI makes this a bit more difficult than Wishbone, simply because there's no bus abort capability in AXI.  One broken component will kill the rest of the design.  That's why it's so important to formally verify AXI components.

If you are just starting out, then I'd try to write an AXI-lite master rather than an AXI one.  It's much easier.  (Calculating burst sizes can be a real challenge when using AXI, and those AXI ID's can be a real pain to work with when reading.)

At this point, you should now have several examples to work with.  It's time to start building and making mistakes that you can then learn from.  Were this my project, I'd start with SymbiYosys and the open source formal properties for AXI-lite.  (Use the master properties faxil_master.v, not the slave properties--they both exist in the same repository I've linked you to before.)  If you can prove that your design meets those properties while still doing (whatever it needs to do), then you'll be there.

Dan

View solution in original post

0 Kudos
MuzamilFarid
Adventurer
Adventurer
921 Views
Registered: ‎04-12-2020

@dgisselq 

I cant thank you enough for all the help

I will work  on it and probably bother you more on the way 

thanks again

0 Kudos