Custom IP

[PoojaN]

Hi!

I am using Arty A7 board with Vivado 2019.1. 

I wanted to get familiar with IP Integrator. I followed all the tutorials available for it.

Now I want to interface RTL and IP blocks, so I wrote a simple Verilog code for an AND gate using buttons and LEDs and created a block of the code by 'Add Module to Block Design'.

It looks like this,

Now I wanted to integrate it with the AXI GPIO block, but whenever I try to make connections, Vivado says 'No Ports found'.

Am I doing it wrong? How can I go about it any further? Or can anyone tell me just how to glow a few LEDs using buttons with only IP and not code.

-P

 

[D@n]

@PoojaN,

Welcome to the wonderful world of graphic design.  I avoid it like the plague, since I worry that it conceals key details from the beginning designer--but that's another story for another day.

You can read how you can go about creating an AXI component here.  You can then tear the guts out of that component and start over with something that works (Xilinx's was broken last I checked), perhaps something like this one.  If AXI is too complicated for you, feel free to try AXI-lite.  Again, Xilinx's demo AXI-lite core is broken but you can find a non-broken one here that you can use.  That said, the process is similar.

As for the GPIO core ... I think it's intended to connect to external ports only, with the feature that the I/Os can be redirected on command to be either inputs or outputs.  Personally?  I wouldn't use it.  The interface offered by the two cores linked above would be superior if you can use it.  What do I mean by superior?  I simply mean that there's been more than one person disappointed at how fast they can toggle an I/O from a CPU.  The AXI GPIO core takes 5 clocks just to toggle an LED, in addition to any bus delays you might struggle with.

Dan

[xc6lx45]

is it possible that you simply need to right-click the ports, "make external" or the like?

[PoojaN]

Hi @D@n

Thanks for your reply. I will read through all the material that you have posted. 

But personally I think, shouldn't this be easy and user friendly rather than being so complicated?
 

-P

[artvvb]

Howdy,

You can absolutely connect a custom module to an AXI GPIO, though, as D@n mentioned, it is not the optimal choice.

To connect the outputs of a custom module to the board's LEDs: Select your module's LED pin, right click on it, and click "Make External". Note the name of the new port that gets created, then uncomment and edit the line/s of the master XDC file that correspond to the LED to use the port's name.

If you expand the AXI GPIO IP's GPIO interface, you can see the individual ports that make it up (*_i, *_o, *_t). These ports can be connected to a custom module manually, by clicking and dragging from one port to the other. You will likely need to configure the AXI GPIO so that it's GPIO interface is "output only" and has a width that corresponds to the width of the module port you want to connect it to - you will probably need to group your "button0" and "button1" ports as a single bus.

The above is plenty to get you started, but, for what it's worth, you can also add GPIO interfaces to your custom module using the syntax found in Vivado's Language Templates (found in the Flow Navigator under the Project Manager) under your language's IP Integrator HDL section.

Thanks,

Arthur

[D@n]

@PoojaN,

You're not the first person who has asked this.

If you just want to blink an LED, then I'd recommend a different approach that avoids all the pain with AXI in the first place.  (You don't need AXI ...)

If you want to start interacting with AXI cores, then you'll need to learn AXI.  Sadly, this isn't as simple as it sounds.

1. Xilinx picked the AXI bus to connect all their components with.  This may have something to do with their ARM integration, since if I understand correctly AXI is an ARM creation
2. AXI is not a simple bus to work with.  Unlike Wishbone, it has five channels associated with it each of which can stall.  These are the read address channel, the write address channel, the write data channel, the read response channel and the write response channel.
3. One bus failure, and your device will lock up.  In my experience, using an ARM+FPGA chip, lockups could only be fixed by cycling the power leaving you ever wondering what had caused the problem.  Part of the problem is that the AXI standard has no way of recovering following a dropped response other than a total system reset.  As I've implemented Wishbone, you can just adjust one wire (the cycle line--but that's another story) and start over.  You can even use a timeout to clear the bus if a peripheral has not responded within an expected period of time.  Not so with AXI.
4. AXI is so difficult to work with that not even Xilinx could get it right.  (See the links above)  When I first discovered these bugs, I wondered that no one had found them before.  For example, two writes in a row would lose a response and lock up the bus if ever there was the slightest amount of backpressure on the return channel.  (Something Wishbone doesn't have to deal with, since there's no way to stall a Wishbone acknowledgement)  It would seem as though very few individuals ever simulated their cores with backpressure (i.e. either BREADY or RREADY signals low), and so they never noticed these bugs.  Similarly, some configurations of the interconnect might trigger the bugs while others wouldn't.  Imagine adjusting the glue that holds your design together only to find your design starts failing.  What would you blame?  The interconnect, right?  When in fact it was their demonstration core logic at fault that everyone was copying.
5. I've now fielded several questions in the last several months alone on Xilinx's forums from users who've struggled with these bugs.  If you do searches, you'll discover that folks have been struggling with these sorts of problems ever since Xilinx started using AXI.  In one recent post, a software engineer posted that his FPGA engineer had left, leaving them with a "working" design.  He then adjusted the software within the design and the whole design now froze any time he tried to write to their special IP core twice in succession.
6. I'm hoping Xilinx will fix these bugs (soon).  I haven't checked their latest release since reporting them, but I do expect them to fix the bugs in the near future.
7. It's not just Xilinx either.  I'm currently verifying the (ASIC) soft core of a major (unnamed) vendor.  Much to my surprise, despite a team of highly paid professional engineers working to produce this amazingly complex core , and despite the fact that they created a simplified subset of the AXI interface standard to work with ... they still didn't get the AXI interface right.

Realizing how difficult this was, I tried to simplify the task by creating a couple of cores.  One showing how to build a bug-free AXI-lite slave (link above), another showing how to build a bug-free AXI slave (link above again).  I also shared an AXI bridge implementation that, if you place your core downstream of it, you'd be guaranteed to meet the AXI protocol--even if it slowed you down a touch.  I also shared the code for verifying that an AXI-lite component works--you are free to try it out yourself to know if your core still works after changing it.  If you like using Wishbone, I've posted an AXI-lite to Wishbone bridge, or even a Wishbone to AXI bridge in case you want to access your DRAM memory.  I also think you'll find that all of these cores, save perhaps the bus fault isolator core, will have better performance than Xilinx's logic ever had.  Whether or not you use these options (or give up on AXI as I've tried to do) ... well, that's up to you.

Forget what the sales brochures tell you, we aren't playing with legos here.  There's more required to hook things together then just plugging them into each other--especially if you want something that works reliably when you are done.

Just want something simple?  Learn Verilog or VHDL.  At least then you'll be the one responsible for your own bugs. 

Dan

[PoojaN]

@D@n Thank you for the detailed explanation!

I wanted to learn about the IP cores, so I thought that I would start with something as simple as blinking an LED. But looking at how working with IP cores is, I think it would be better if I don't take up on such a herculean task right now.

I will read up all the material that you have posted.

Thank You!

 

-P