Should i care about AXI4 for my project ?

[ker2x]

Friendly greetings !

I'm a beginner, i haven't received my board yet and the lasts time i played with FPGA was a few years ago with Xilinx ISE and a bare Spartan-6 FPGA (with UART usb interface). It was a disaster
I'm back, with a proper dev board from Digilent and a much easier to use vivado.

So i'm playing with vivado in the meantime (webpack edition) and the block designs.
I like it, of course, and now i want to create my own block and IP and make my project (a 6502 computer, it's the end-goal, but i won't start with that).

Every single tutorial i watched to create blocks, they created AXI4 module.
I'm not really sure want AXI4 really is to be honest. To me, it just look like a protocol (+ some other convention) as a common interface to talk to the Zynq, Microblaze, and a bunch of IP so they are compatible to each-others.

But now i'm a bit confused, since all blocks used AXI4, does it mean i can't create useable block without using AXI4 ? it is a requirement ?
Should i bother with it because i'll be glad later in the future that my blocks use AXI4 ? Or because it will help me to design better reusable module at the cost of higher complexity ?
Or is it just Xilinx pushing marketing hype for AXI4 ?

The answer will be "it depends", probably. If i wanted to add a microblaze in my project i guess the answer would be "yes because you have to". But if i don't use a microblaze or a zynq ... ?
Of course, i don't really want to use AXI4 since i'm not even sure what it is in the first place. But if you tell i should use it... well... i will 

PS : i triple checked the UART block that come with the board and it's an AXI block. So i have to have design at least 1 AXI module.
PPS : do i even make sense or did i completely misunderstood the whole axi stuff ? (it's highly probable)

thank you 

[ataradov]

AXI is the native bus of the CPU core. So if you want a peripheral that is directly attached to the CPU bus, then yes, AXI is unavoidable. But for typical peripherals, like timers and GPIO port AXI is a huge overkill.

Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.

I have not followed the latest development with buses, I don't believe they would want you connecting UARTs on the CPU bus. That just does not make any sense. So in any case, it is likely to be connected to some sort of AXI-AXI bridge.

And if you don't want to use any of the processor cores, then there are easier ways to get a UART working. But if you want to talk to their IPs from your logic, then you have to use AXI, obviously.

[ker2x]

AXI is the native bus of the CPU core. So if you want a peripheral that is directly attached to the CPU bus, then yes, AXI is unavoidable. But for typical peripherals, like timers and GPIO port AXI is a huge overkill.

Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.

I have not followed the latest development with buses, I don't believe they would want you connecting UARTs on the CPU bus. That just does not make any sense. So in any case, it is likely to be connected to some sort of AXI-AXI bridge.

From what i understand from the (simple) tutorials, they just create a simple verilog source (a few line of code for a full adder), click on a magic button to generate the AXI block and the whole AXI stuff is just a wrapper.
The "original" verilog code doesn't care about AXI, bus communication, eventual protocol negociation, etc.

Still from my understanding, using AXI allow the block design tool to understand that the clock is a clock, the reset is a reset, and so on, in order to autoconnect everything.
And probably do some other automagic stuff like generating the wizard in order to modify the block configuration. (eg: bus width)

My question still remain despite that. Do i have to use AXI in order to create block useable in the designer ?
And even if it's not a hard requirement : should i do it anyway ?

[ataradov]

From what i understand from the (simple) tutorials, they just create a simple verilog source (a few line of code for a full adder), click on a magic button to generate the AXI block and the whole AXI stuff is just a wrapper.
The "original" verilog code doesn't care about AXI, bus communication, eventual protocol negociation, etc.

Well, it would have to care to a certain extent if it has logic that is driven by the commands from the bus. If it is an adder, it would have to know how to take two input values and return the result.

My question still remain despite that. Do i have to use AXI in order to create block useable in the designer ?

If you want to use processor cores, then you have to use AXI, for sure. I have not worked with Vivado to tell if its designer is useful without the processor core. I personally would stay away from graphical drag and drop designers as far as I can.

[ker2x]

If you want to use processor cores, then you have to use AXI, for sure. I have not worked with Vivado to tell if its designer is useful without the processor core. I personally would stay away from graphical drag and drop designers as far as I can.

I'm not planning to use any IP except the ones provided by digilent : UART and DDR2 Controller.
"Digilent will provide a VHDL reference module that wraps the complexity of a DDR2 controller and is backwards compatible with the asynchronous SRAM interface of the CellularRAM, with certain limitations."
I will use it because i understand that DDR2 is notoriously difficult to use for a beginner.

I understand why you wouldn't want, or even recommend, to use a graphical tool. Because you know how to do stuff without it.

But... i already tried in the past. With a barebone FPGA and Xilinx ISE. The entry barrier was just too much for me. I gave up, it was too much. i had to learn everything from zero without anyone to help me.
And i still don't know anyone in my social circle who even know that FPGA exist and that Verilog isn't something made by Veritas 
So, yeah, i'll use graphical magic.

[ataradov]

The DDR wrapped into SRAM-like interface is a good idea and it should be very simple to use.

The graphical designer in this case will solve the easiest part of the problem. You will still have to write the code behind the blocks. And interconnecting the blocks from the code is trivial.

I think the designer will confuse you even more, not help. The designers is fine for CPU-based system with buses, since it is a lot of similar signals going to the peripherals. Doing that from the code is annoying.

[ker2x]

The DDR wrapped into SRAM-like interface is a good idea and it should be very simple to use.

The graphical designer in this case will solve the easiest part of the problem. You will still have to write the code behind the blocks. And interconnecting the blocks from the code is trivial.

I think the designer will confuse you even more, not help. The designers is fine for CPU-based system with buses, since it is a lot of similar signals going to the peripherals. Doing that from the code is annoying.

Well, my end goal is to create a CPU inspired from the 6502 and a full computer while i'm at it. So...
My first project will involve playing a lot with the VGA port. I just can't wait to do some graphical demo, understanding VESA and the differents mode, sprites, characters, keyboard, sound, ...
Basically doing some hardwired stuff involving a computer, but without the CPU yet.
Then display the bits in RAM to the screen, then add some keyboardy stuff, blip and bloup from the audio, and so on.
building block i'll later be able to partially or fully reuse.

It's mostly wishful thinking of course. it will probably instead involve a lot of tears, sweat, and blood frustration.

[ataradov]

This is a good goal and overall I would not call this unimaginable even for a beginner. There are lots of examples for all of this.

But again, the designer is not going to be helpful here at all. Modern designer in Vivado is not the same thing as graphical entry languages of the old days, it is just a way to connect blocks together. This is easy to to from the code. The hard part is to fill the blocks with the actual logic.

[ker2x]

The hard part is to fill the blocks with the actual logic.

Well, yeah.
I could use pen and paper to draw some block diagram. Just like one would do a class diagram when writing OOP, or UML for a database design.

I just came out of a long debate because i wanted to do my project out of TTL chips and everyone tried (successfully) to convince me to use an FPGA.
I finally got convinced when someone told me i could simply create 74xx chips in verilog/vhdl and connect them using the graphical tool. (well, it convinced me but that would be silly to actually do it)

And now you guys tell me to not even use the graphical tool, you'll kill me before i even receive my card. give me a break, my poor mind is breaking

[ker2x]

And we're super offtopic btw, my question was about AXI   

[Someone]

So i'm playing with vivado in the meantime (webpack edition) and the block designs.
I like it, of course, and now i want to create my own block and IP and make my project (a 6502 computer, it's the end-goal, but i won't start with that).

Start with the big picture, a 6502 computer, good. Now throw away all your thinking so far as its taken you away from the goal.

Of course, i don't really want to use AXI4 since i'm not even sure what it is in the first place. But if you tell i should use it... well... i will 

If you blindly use things you don't understand it ends up like this:
https://www.eevblog.com/forum/fpga/unspecified-io-standard-in-vivado-when-trying-to-set-axi-gpio-to-1-bit-width/

And now you guys tell me to not even use the graphical tool, you'll kill me before i even receive my card. give me a break, my poor mind is breaking

The high level tools such as the system level block "flow" are designed around high level abstractions. It can be abused to do schematic entry as is available in other tools, but that isn't supported so you're on your own.

People have moved away from schematic entry because:

• its hard to edit, add a new part in the middle of a schematic and you need to move everything around to fit, add a line of code is easy
• its hard to compare, diff tools on text entry make it easy to follow/track changes to a design
• there is no standard, your schematic design is not portable to other tools or possibly even other devices

but back to your original questions..

I'm not planning to use any IP except the ones provided by digilent : UART and DDR2 Controller.
"Digilent will provide a VHDL reference module that wraps the complexity of a DDR2 controller and is backwards compatible with the asynchronous SRAM interface of the CellularRAM, with certain limitations."
I will use it because i understand that DDR2 is notoriously difficult to use for a beginner.

There are many different UART "IP" available. You don't mention the actual board or chip you plan to use, there are different UARTS. Some are already in the "hard" resources and cannot be changed, but most are just a wrapper around some lower level code which implements the UART on the FPGA fabric. If you have a different interface and aren't using hard resources, then you usually create your own UART "IP" to match your requirements.

Building an AXI compliant 6502 could be an interesting project, and would let you reuse all the AXI IP. But your original plan was likely the opposite of taking the typical 6502 and building your own peripherals.

[asmi]

Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.

I'm sorry, but what bus is simpler than AXI MM/AXI Stream? I think it's as simple as it gets.

[Someone]

Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.

I'm sorry, but what bus is simpler than AXI MM/AXI Stream? I think it's as simple as it gets.

Most things without wait states/logic, there are plenty of busses in use that are non-blocking.

[exmadscientist]

Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.

I'm sorry, but what bus is simpler than AXI MM/AXI Stream? I think it's as simple as it gets.

Most things without wait states/logic, there are plenty of busses in use that are non-blocking.

When talking about AMBA/AXI4, it is important to remember that there are three flavors of it:

• AXI4, which really should be called "AXI4-Full"
• AXI4-Lite
• AXI4-Stream

The Full and Lite protocols are indeed pretty heavyweight. (But they might make sense if you'd be rolling your own version of any of the features they provide.) AXI4-Stream, in contrast, is nice and lightweight. On my last FPGA project I converted the interface for any module I touched over from "homebrew handshaking" to AXI4-Stream; mostly this just involved renaming a few signals. It's a great starting point for gluing together logic blocks, and is my go-to for the interface of a new custom component.

[ataradov]

But in any case, it is probably not a good idea to have many "slow" peripherals attached to the main CPU bus. Closing timings with a lot of slaves may be hard. Even if you use AXI entirely, it will be better to hide the peripherals behind AXI-to-AXI bridges.

[ker2x]

The board is a Nexys 4 DDR.

The USB-UART chips is a FT2232HQ from FTDI, the block provided is just the Xilinx UART-lite IP, it use AXI4-Lite.
The ethernet port have no controller on its own so it's Xilinx IP too, i have no use for it (yet).
The USB/SDCARD controller is a PIC24, i believe it's just SPI.
The VGA port is just 14 resistor and physical connecter, no IP are provided, nor needed. i want to develop my own.
Misc device (temperature, ...) are either I2C or SPI.

As for the DDR2/SRAM block, i didn't check yet, but from my understanding it won't be a Xilinx IP.

[ker2x]

But in any case, it is probably not a good idea to have many "slow" peripherals attached to the main CPU bus. Closing timings with a lot of slaves may be hard. Even if you use AXI entirely, it will be better to hide the peripherals behind AXI-to-AXI bridges.

It's too early for me yet to be confident about my design. But :
I'm not planning to connect any peripherals to the main CPU Bus. I have a slow 8bit 6502 connected to a fast & massive 128MB DDR2.
The floppy will be in RAM, Screenbuffer in RAM, everything in RAM, so the periperhals will be much faster than the cpu. Why bother to do any other way ?
I could even use the BRAM for the computer RAM. I have 4Mb On the Artix-7 100 and the max adressable ram in 16bit is 64Kb. 

[ataradov]

For 6502 none of this discussion matters at all. You can approach it the most unoptimal way you can think of and it will work fine. It starts to be a concern when you need your buses to work at > 100 MHz.

[ker2x]

For 6502 none of this discussion matters at all. You can approach it the most unoptimal way you can think of and it will work fine. It starts to be a concern when you need your buses to work at > 100 MHz.

Exactly 

[ker2x]

If i wanted to do serious number crunching with my FPGA i would have bought a Zynq.
I know my self, I would have ended up with a glorified Raspberry Pi and spend all my time playing with HLx and/or SDAccel. And do C/OpenCL instead of Verilog.

[asmi]

Most things without wait states/logic, there are plenty of busses in use that are non-blocking.

Like what? AXI uses the simplest handshake method there is (ready/valid). AXI specification allows tying ready high if the slave is always able to accept data.
Please show an example of "non-blocking" bus that would still guarantee data delivery.

[asmi]

The Full and Lite protocols are indeed pretty heavyweight. (But they might make sense if you'd be rolling your own version of any of the features they provide.)

You make it sound like they are interchangeable. They are not. AXI Full and Lite buses are memory-mapped, while AXI Stream is not. If you need to provide addressable access to your registers, or need to have such access to something else on a bus, there is no other option.

AXI4-Stream, in contrast, is nice and lightweight. On my last FPGA project I converted the interface for any module I touched over from "homebrew handshaking" to AXI4-Stream; mostly this just involved renaming a few signals. It's a great starting point for gluing together logic blocks, and is my go-to for the interface of a new custom component.

This is good if you need to stream data (hence the name).

[rstofer]

Until very late in the ISE game the Xilinx IP wasn't available at no cost.  Hence, I have never used it.  But the AXI stuff is related to the Xilinx MicroBlaze core and, if you're just doing a 6502, you won't be using that at all.

Another hint:  I have a fully functional IBM 1130 minicomputer and an implementation of the LC3 processor along with a couple of Z80 projects and I have never used a bit of Xilinx IP.  It just doesn't play into what I want to do - build CPUs.  Now, if I were building some 'gee whiz' project that needed a fully featured core and I didn't want to build all of the logic, of course I would head for MicroBlaze.  That project would be about the application, not the core.

Here's the thing, CPUs are, at their heart, nothing but state machines.  You need to know how to code them.  I would start by looking at the state diagram for the LC3 project and think about how that kind of diagram could be used to describe a 6502.  Not necessarily a cycle accurate implementation but a functionally equivalent  one.  Or you can go for cycle accuracy, there's a core like that on OpenCores.org

First up, you must install the Digilent board files because they are going to help you create the Constraints File for your project.  You say you like Vivado more than ISE?  Wait until you deal with the new and improved Constraints File.  What a gigantic PITA!  Nevertheless, it is what it is and the board files give you a leg up.  On reflection, I'm not so sure about that but install them anyway.  There's a discussion at Digilent, I think.

The next step is Hello World - a blinking LED.  The clock frequency is 100 MHz so you need to divide by 50 million of so.  Implement a 25 bit counter and use the high bit to drive the LED pin.  I have attached a .vhd and .xdc file for your perusal.  I apologize for the regrettable entity and file names but I ripped the code from my LC3 project rather than starting from scratch.  Exercise:  Build another project and name the files and entity properly as HelloWorld to match what I assume is your project name.  Pare down to a minimal set of libraries.  They will all be necessary later but not for a blinking LED.

When you create the project, don't forget to click on the Boards tab and find your board rather than the device.  You can choose to add the source and constraint file (in separate steps) as you create the project.  If you do, they will be considered 'imported' and a little farther down in the files tree.  Or, you can create, copy and paste the files.  That gives you a chance to name the files properly.  Then all you need to do is a little Replace LC3 with HelloWorld to clean up the mess.

I have forgotten where my fully featured .xdc file came from  I have included one for your use.

ETA:  When I first started with ISE, I found a step-by-step tutorial to make an LED blink.  It was very helpful!  Vivado seems more involved so I thought I would add a README.txt file that should come somewhere close to the proper procedure for creating the HelloWorld project given the files in the .zip archive

[rstofer]

Remember, VHDL doesn't like open collector 'wired and' buses.  Actually, it isn't VHDL that has a problem, it's the internal construction of the chip.

You may think you can 'Z' a signal but what will probably happen is that the bus will be implemented as a MUX.  If you have several registers that talk on a bus, you might as well start right off implementing the MUX.  When you draw the block diagram, just put the MUX on paper right from the beginning.  ISE used to whine and snivel about attempts to implement wired-and.  I'm not sure about Vivado.

You can create in-out signals on IO pins as would be required to talk to off-chip devices like memory over a bi-directional bus.

[rstofer]

The hard part is to fill the blocks with the actual logic.

Well, yeah.
I could use pen and paper to draw some block diagram. Just like one would do a class diagram when writing OOP, or UML for a database design.

I just came out of a long debate because i wanted to do my project out of TTL chips and everyone tried (successfully) to convince me to use an FPGA.
I finally got convinced when someone told me i could simply create 74xx chips in verilog/vhdl and connect them using the graphical tool. (well, it convinced me but that would be silly to actually do it)

And now you guys tell me to not even use the graphical tool, you'll kill me before i even receive my card. give me a break, my poor mind is breaking

I have only used schematic entry once and that was to instantiate a full adder because I couldn't seem to figure out how to do it in code.  That was a long time ago...

If you wanted to build up 74xx components, as they are called, you would simply create the code in a file and instantiate it in your design.  This will leave you with a Port Map of the IO pins.  You connect the various pins to other devices with common everyday signals which you have to declare at the top of the file.  There's nothing special about this, every device you add, whether UART, RAM or any other component is instantiated the same way.

Assume that in another file, named uartRx.vhd, I have designed the entity for the UART receive component.  In an upper level, in my case the top level, I want to incorporate it in the design and wire it up.  That instantiation looks like this:

Code: [Select]

    -- uartRX is the KEYBOARD device -- INPUT
    inst_uartRx: entity work.uartRx
        Port Map (
            clr         => Reset,
            clk         => ClkIn,
            ce16        => ce16,
            serIn       => Tx,
            rxData      => KBDRin(7 downto 0),  -- 'in' from the CPUs point of view
            newRxData   => newRxData
        );
[/font]


Every signal on the left of the => symbol is defined in the entity file.  Every signal on the right is where I connect it at this level.

You can see how a 7400 would have 8 inputs and 4 outputs (1A, 1B, 1Y; 2A, 2B, 2Y; 3A, 3B, 3Y, 4A, 4B, 4Y) where the As & Bs are inputs to the entity (outputs from some other logic) and the Ys are the outputs (inputs to logic at this level).