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

Block RAM access with AXI Master Interface

Jump to solution

Dear all,

I have just begun working with Zynq device and currently working on a project. My query is very simple.

I want to perform some read and write transactions to BRAM from custom AXI master interface by writing some custom logic in VHDL. 

Is this possible? and if so how could that be done, Can some one please direct me to an example? I will be highly thankful 

 

0 Kudos
1 Solution

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

@MuzamilFarid,

Did my reply answer your question?  You seem to have gone on to a second, follow up question,

You originally asked if you could build an AXI master interface by writing custom logic in VHDL, and then asked further for an example.  I provided you with one example, one that I felt was fairly well documented, but was in Verilog.  I also pointed out that Xilinx's examples were broken.

Did these answer your question?  You stated that you are now confused, but haven't asked about anything in the answer I gave you.  Is that what confused you?  If so, how?

Regarding the default code generated by Vivado's IP packager:

  • The AXI-lite slave code generated by the packager attempts to generate a peripheral with a small number of controllable registers in it.  It would be a great starting point for new peripheral designs if it wasn't known for causing your entire design to hang under certain circumstances.  In my blog article examining this core, I've discussed both the bugs and how to fix them.  Other following articles have discussed how to generate a new AXI-lite peripheral from scratch.  It's not as hard as it sounds--especially if you use formal methods to find any bugs along the way.
  • The AXI slave code generated by the packager attempts to generate a block RAM peripheral.  This would be a great starting point for designs that depended upon internal memory, save that 1) it's also broken, and 2) the memory is buried within the design so that accessing it by both the peripheral and the bus is a challenge to work with.  How is it broken?  As with the AXI-lite slave example, it doesn't follow the AXI protocol properly.  There are actually several bugs within it.  Perhaps the worst is that it will drop acknowledgments, causing the bus to hang.  Many users have worked with this slave code and been surprised when their entire bus locked up.  Further, AXI is supposed to be designed for speed.  However, this generated core doesn't really achieve full bus throughput.  As a result, when I built my own AXI slave example, I built one that 1) worked (Sorry, Xilinx, but yours is quite broken), 2) achieved 100% throughput for both reads and writes across burst boundaries even (at best, Xilinx's only gets 50% read throughput, and that's not across bursts), and 3) exposed the block RAM interface externally to make it easier to integrate with the simpler portions of any design.
  • The AXI-lite master demonstration core writes a pattern to memory, and then reads it back again.  On reading the same pattern back, it returns a success signal otherwise an error signal.  If used properly, it shouldn't break your bus.  axil-full-pattern.pngThat said, it's not necessarily a great example to work with because it doesn't expose a simpler interface to build your design against.  Further, if your goal was to verify that a slave worked by using this core, it ... doesn't make for a very complete test.  1) It doesn't test multiple requests at once, 2) it doesn't check whether the WSTRB signal works properly, 3) it doesn't test more than a couple bottom bits in the bus data path, etc.  In other words, it works, but it might not nearly be as useful as you would like.  I recently posted an alternative to this core that works from a simpler bus interface--feel free to examine that if you would rather.  That article also discusses how to make AXI masters in general, and goes over the various categories of AXI master you might come across.
  • The last example, Xilinx's AXI (full) master example is similar to the AXI-lite master example, save that the full master issues burst requests.axi-full-pattern.pngBe careful, if you try to start with this code, since it doesn't break it's bursts on 4kB boundaries as required by the AXI spec.  Whether or not your AXI (full) master will have this problem if you copy this design depends upon how you configure it.  As with the AXI-lite master design above, however, it's not the greatest design to start from and rework for your own purposes since it doesn't really expose an interface you can work with/from for that purpose.

Bottom line: Be careful where you get your examples from.  They might come back to burn you later.  Similarly, be very thorough in how you verify your own designs.

Let's see, that should answer your question of, "what exactly is this default code doing?"

Your next question was whether or not it was "possible to just simulate this on Vivado simulator so i can just see how these AXI master signals are behaving?"  The answer to that question is, Yes, it is possible.  Vivado has an AXI VIP core for this purpose.  Be aware, this VIP is not likely to expose the bugs listed above.  It's not, nor was it really intended to be as far as I can tell, a complete AXI verification solution.

You can read more about the AXI designs I discussed above, both why Xilinx's demonstration designs are broken as well as how to build better AXI designs, on the ZipCPU blog.

Dan

View solution in original post

0 Kudos
4 Replies
dgisselq
Scholar
Scholar
813 Views
Registered: ‎05-21-2015

@MuzamilFarid,

You might find this example useful. The resulting interface is almost a block RAM interface, and should be easy enough to modify for your own purpose.

Be aware, there's a lot of documentation out there regarding creating an example from auto-generated IP packager "create and package new IP" code.  This Xilinx demonstration design is broken .  The above example should work, though.

Dan

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

@dgisselq 

Thanks alot for your reply.

 

I have some very basic confusions, please take some time to address them.

 

When i create custom AXI peripheral in vivado, (Master, Slave, anyone). It generates a default code. What exactly is this default code is doing? 

If i understand correctly. In case of AXI master interface, this code is performing read and write transactions? Is it possible to just simulate this on vivado simulator so i can just see how these AXI master signals are behaving? please do reply

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

@MuzamilFarid,

Did my reply answer your question?  You seem to have gone on to a second, follow up question,

You originally asked if you could build an AXI master interface by writing custom logic in VHDL, and then asked further for an example.  I provided you with one example, one that I felt was fairly well documented, but was in Verilog.  I also pointed out that Xilinx's examples were broken.

Did these answer your question?  You stated that you are now confused, but haven't asked about anything in the answer I gave you.  Is that what confused you?  If so, how?

Regarding the default code generated by Vivado's IP packager:

  • The AXI-lite slave code generated by the packager attempts to generate a peripheral with a small number of controllable registers in it.  It would be a great starting point for new peripheral designs if it wasn't known for causing your entire design to hang under certain circumstances.  In my blog article examining this core, I've discussed both the bugs and how to fix them.  Other following articles have discussed how to generate a new AXI-lite peripheral from scratch.  It's not as hard as it sounds--especially if you use formal methods to find any bugs along the way.
  • The AXI slave code generated by the packager attempts to generate a block RAM peripheral.  This would be a great starting point for designs that depended upon internal memory, save that 1) it's also broken, and 2) the memory is buried within the design so that accessing it by both the peripheral and the bus is a challenge to work with.  How is it broken?  As with the AXI-lite slave example, it doesn't follow the AXI protocol properly.  There are actually several bugs within it.  Perhaps the worst is that it will drop acknowledgments, causing the bus to hang.  Many users have worked with this slave code and been surprised when their entire bus locked up.  Further, AXI is supposed to be designed for speed.  However, this generated core doesn't really achieve full bus throughput.  As a result, when I built my own AXI slave example, I built one that 1) worked (Sorry, Xilinx, but yours is quite broken), 2) achieved 100% throughput for both reads and writes across burst boundaries even (at best, Xilinx's only gets 50% read throughput, and that's not across bursts), and 3) exposed the block RAM interface externally to make it easier to integrate with the simpler portions of any design.
  • The AXI-lite master demonstration core writes a pattern to memory, and then reads it back again.  On reading the same pattern back, it returns a success signal otherwise an error signal.  If used properly, it shouldn't break your bus.  axil-full-pattern.pngThat said, it's not necessarily a great example to work with because it doesn't expose a simpler interface to build your design against.  Further, if your goal was to verify that a slave worked by using this core, it ... doesn't make for a very complete test.  1) It doesn't test multiple requests at once, 2) it doesn't check whether the WSTRB signal works properly, 3) it doesn't test more than a couple bottom bits in the bus data path, etc.  In other words, it works, but it might not nearly be as useful as you would like.  I recently posted an alternative to this core that works from a simpler bus interface--feel free to examine that if you would rather.  That article also discusses how to make AXI masters in general, and goes over the various categories of AXI master you might come across.
  • The last example, Xilinx's AXI (full) master example is similar to the AXI-lite master example, save that the full master issues burst requests.axi-full-pattern.pngBe careful, if you try to start with this code, since it doesn't break it's bursts on 4kB boundaries as required by the AXI spec.  Whether or not your AXI (full) master will have this problem if you copy this design depends upon how you configure it.  As with the AXI-lite master design above, however, it's not the greatest design to start from and rework for your own purposes since it doesn't really expose an interface you can work with/from for that purpose.

Bottom line: Be careful where you get your examples from.  They might come back to burn you later.  Similarly, be very thorough in how you verify your own designs.

Let's see, that should answer your question of, "what exactly is this default code doing?"

Your next question was whether or not it was "possible to just simulate this on Vivado simulator so i can just see how these AXI master signals are behaving?"  The answer to that question is, Yes, it is possible.  Vivado has an AXI VIP core for this purpose.  Be aware, this VIP is not likely to expose the bugs listed above.  It's not, nor was it really intended to be as far as I can tell, a complete AXI verification solution.

You can read more about the AXI designs I discussed above, both why Xilinx's demonstration designs are broken as well as how to build better AXI designs, on the ZipCPU blog.

Dan

View solution in original post

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

@dgisselq 

thanks for detailed explanation

0 Kudos