Should i care about AXI4 for my project ?

[rstofer]

FreeRangeVHDL Listing 9.1 shows a method for defining those logic chips you wanted to use.  Of course, you have to decide if you are defining a logic gate, perhaps 1 of 4 NANDs in a 7400) or you are defining the chip which will have ports for all 8 inputs and 4 output.  Your choice.

[Someone]

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.

You're probably arguing the semantics of "bus" now, an async SRAM has no handshake and offers up a bus, the same sort of interface can be applied to any number of register interface peripherals.

[rstofer]

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.

In terms of creating blocks with VHDL or Verilog (and maybe System Verilog, IDK), nothing is unique about Vivado.  Just add a blank file to the system and start typing.  Because I want to build very simple things, I don't use any of the Xilinx IP.  If I ever get to the point of using DDR memory and don't plan to use Digilent's component, darn right I will use the MIG IP.  Nobody in their right mind wants to code that interface.  If that drags in some other requirements, I would get over it.  Just go with the flow...

Here's some really good news:  There is NO schematic editor in Vivado

https://forums.xilinx.com/t5/Design-Entry/Schematic-Design-Entry-Tool-in-Vivado/td-p/278260

As to the UART, I think I grabbed it from OpenCores.org.  There are 3 files:  Receiver, Transmitter and BaudRateGenerator.  There's no copyright so I don't know who wrote it.  If it seems useful, I can zip up the files.  It certainly works ok for my LC3 project but there are many alternatives out in the wild.

The parameters for the divider in the baud rate generator are given at the top level, in my case.  Ordinarily, the parameters are given in the generator itself but I didn't want them buried that deep in the tree.  Just in case I had to change baud rates.

ETA:  OpenCores has some dodgy code and I have read many threads where people don't like OpenCores.  Well, I guess you get what you don't pay for!  Like all open source, some is good, some is bad.  It can't hurt to look and at least see how somebody else approached the problem.

[rstofer]

In your other thread, I discussed Hamster_nz's code to initialize BlockRAM at design time from the contents of a .hex file.  Think about how you plan to boot your 6502.  When first turned on, all of the BlockRAM is zeroed.  You need boot code and the way to do it is to use a 6502 assembler to create a .hex file and Hamster_nz's code to build the .hex file into the .bit file.

As an exercise for the reader, use the .hex file as a loader to read an OS off of the SD card.  SD card reader code by others.  Note that OpenCores has their own bus interface so it might take a bit of effort to convert their SD card code to something you can use.

Big hint:  I find the 'dd' command in Linux to be very helpful for laying down raw images on SD and CF cards.

ETA:  If the boot code is initially in the BlockRAM, it will be present at boot time - once!  If you use a Reset signal to reset the state of the core, that's not the same as loading the .bit image so the code won't be present (necessarily).  One way to solve this is to create a process that copies the code from another chunk of BlockRAM into the main memory at boot time.  I do this on my IBM1130 as the first few states of the FSM before I ever get to Instruction Fetch.  Or you could map the block in and out of the memory map.  Lots of alternatives but just realize when you will, and won't, have BlockRAM initialized.

[exmadscientist]

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.

You are, of course, quite right. Slightly less hastily, the points I was trying to make were:

• Don't confuse AXI4-Stream and AXI4-Lite/Full. They are very different protocols.
• If you find yourself re-implementing features that AXI4-Lite would provide for you, such as addressing &c, you should consider just adopting AXI4-Lite instead of writing your own half-baked implementation.
• If you are writing something for which AXI4-Stream might be appropriate, consider just adopting it outright. The AXI4-Stream specification was carefully thought through by skilled engineers. If you adopt it, you can leverage their work and quickly build robust, well-defined, clearly extensible interfaces. The standard is also simple and easy enough to understand that this is readily feasible. The effort saved in documentation alone can pay for itself quickly.

[OwO]

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.

Actually there is an easier to use handshake protocol (ready/strobe), where data strobes are still allowed N cycles after ready is deasserted... well easier to use when you want to close very tight timings.

[xlnx]

The #1 reason to use AXI4 is that it is a standard. Once every IP complies with a standard, you can focus on their functionality rather than their interfacing. AXI4-Stream and AXI4-Lite are indeed very, very simple. For proper handshaking only a couple of registers are needed. I have written a short introduction in my blog here: http://que.no/index.php/2016/03/13/principles-of-fpga-ip-interconnect/

I would much rather use AXI4 which is a synchronous protocol, rather than "ready/strobe" which might be asynchronous depending on the actual meaning of "ready/strobe".

I have an example VHDL code for an extremely simple AXI4-Lite target with register access if that is of interest.

[OwO]

AXI is what I use for large scale integration (big modules) and internally I can use whatever is most appropriate.

I would much rather use AXI4 which is a synchronous protocol, rather than "ready/strobe" which might be asynchronous depending on the actual meaning of "ready/strobe".

If you mean synchronous as in synchronous logic, then yes it absolutely is synchronous, but if you mean synchronous as in sending a request, waiting for its completion, then continuing then it is not synchronous and that's the point. Being able to close timing means you must accept some latency in flow control, which means very well that data can continue to flow for a bit after you decided it shouldn't. The way to deal with that is a skid buffer, and using AXI requires small skid buffers everywhere while a delayed flow control protocol allows a few bigger skid buffers: https://www.eevblog.com/forum/fpga/some-thoughts-on-axi-pipe-handshake-protocol-and-timing-closure/

[xlnx]

A double-buffer or FIFO is required only if you need to clock data on every clock cycle - apart from that AXI4 (Lite or Stream) does not *require* a buffer. In fact, for AXI4-Lite, there is typically so much latency in communicating with a peripherel, that having extra buffers is a waste of resources. As I said, all handshaking can be handled using a couple of registers, and you get a synchronous design - which is very much desired in RTL code.

[Ditiris]

ker - looks like this got a bit off topic. Hopefully you have a good idea of what AXI is by now. I would say look at the HDL generated by Vivado for an AXI-Lite peripheral and make sure you understand it. That will allow you to talk to your processor or any other block you create within the AXI system.

[rstofer]

I was at the Pynq site yesterday and there is a lot of discussion about making custom IP and connecting it to the AXI interfaces.  I'm not saying it applies here because, in my view, it clearly doesn't but it is worth the time to watch a couple of videos and study the workflow for use with Zynq processors.

https://github.com/Xilinx/PYNQ_Workshop