autofpga VS wb2axip

I use AutoFPGA for connecting my top level components together. It handles bus composition and address assignment for me, while also creating linker, C header and Verilator simulation files for the project. Once a project is set up, reconfiguration is as easy as adding a file to the command line to add a component, or removing a file from the command line to remove a component. Make handles the rest.

I use AutoFPGA for all my bus connections. A single @$(SLAVE.PORTLIST) or @$(SLAVE.ANSPORTLIST) automatically expands into the connections required when instantiating a module. It'll also instantiate the crossbar for you as well.

Yes, I have posted an open source AXI interconnect. Unlike Xilinx's interconnect, mine doesn't automatically bridge between one bus width or clock and another, although some bridges exist in the same repository. Bridges exist, for example, for crossing clock domains, going from AXI3 to AXI4, from AXI4 to AXI4-lite, from AXI4 to a smaller AXI4-lite, and from AXI4-lite to a wider width. It's been enough to keep me from needing my own AXI4 interconnect, although AXI can be a real pain to wire up. As a result, I tend to use AutoFPGA for that purpose.

Now, whether or not AutoFPGA fits the bill for anyone--that's an entirely different question. I suspect the answer is, "No", but that's really a different conversation for a different time/thread. One of the things it can do is compose an AXI bus from multiple master and slave configurations--all using user controlled and very version controllable configuration files. The big problem it has (currently) is the lack of a strong verification suite. That's probably going to hit the top of my to-do list soon enough.

An SoC composer? You'll need something that takes multiple bus components and stitches them together. I've used AutoFPGA extensively for this purpose, and continue to do so today. It's biggest problem? I haven't put a lot of energy into marketing it, so the documentation is more lacking than I would like. Still, it's worked quite well for me and my intermediate tutorial (work in progress) provides some discussion of how to work with it.

AutoFPGA can do simple bus line pattern substitution. For example, these two configuration lines then expand to these 65 lines.

There are also open source versions of many of the pieces you will need. I now use an open source crossbar interconnect for most of my designs. I use AutoFPGA to connect all the pieces together. I mentioned my flash controller above, but I also have a SD Card controller I've used quite successfully. I've also posted a UART to Wishbone bridge and discussed network debugging, both of which I use routinely with the ZipCPU. If for no other reason, these components allow me to load or update software on my CPU even after it's been placed into an FPGA. Of course, many of those components are tied to a Wishbone bus infrastructure. You may find you need a bridge of some type to connect different buses structures together--memory naturally tends to operate at one width and clock, video at another, and your CPU at another, so it helps at times to have a universal bus adapter kit handy.

I generated my own solution to this problem, a solution which I called AutoFPGA. It's not IP-XACT. It configures a design based upon a bus with (potentially) multiple masters and slaves. Configuration files are designed on a per-unit basis, with the intention that a slave (or master) configuration file could be removed to remove that portion of the design from the whole.

If you wish to build a SOC design, you'll need some approach to assembling the bus together. There will be a lot of wires to connect, and a lot of logic to build just to get you off the ground. You'll find several SOC based building tools out there to use. I've built my own, AutoFPGA, which I use for assembling peripherals around a CPU based design. You might find an open source crossbar interconnect to be quite valuable as well. I've built crossbars for AXI, AXI-lite, and Wishbone (pipeline). I know there's a good Wishbone classic crossbar out there as well, I just don't have the link at my fingertips. (Good? It'll slow down your overall clock speed, while yielding poorer performance compared to Wishbone pipeline--but that's just the reality of working with Wishbone classic.)

I've always been partial to my own skidbuffer article and implementation. (You'd expect me to be, they're my own ...) I get your point, though, about some applications needing a registered output. I've come across many, as requirements change from one project to the next. This is why, in my own implementation, I have parameters allowing me to adjust which implementation I'm using. In this case in particular, I have a parameter adjusting whether or not the output is registered. (The outgoing READY signal, though, is always registered--that's the point of the skid buffer in the first place, and what keeps it from being a regular buffer.)

Ref: [1], [2]

Have you considered this article? It goes over the basics of the autocorrelation function, while also illustrating how you can build one with a Wishbone interface. Further, the Verilator logic for this function is kept and maintained on github here. Sure, it uses Wishbone. If you want to use AXI you can either use a bridge, or rework the the interface (it's not that hard ...).

If this is what you want, though, then consider checking out the apply_wstrb function in my wb2axip repository. Perhaps the easyaxil might be the easiest one to start with.

The worst thing that can happen on a bus is a protocol error that causes the device to lock up. Sadly, such errors have been common when using AXI or AXI-Lite--especially since traditional "verification IP" bus models won't catch all circumstances. This is why I make a general (personal) rule that nothing should touch a bus unless it has been formally verified. This check basically guarantees that every bus request gets one (and only one) response. It's not sufficient to verify an IP fully, but it's a good start. You can find my formal verification models for AXI-Lite, Wishbone, and (to some extent) Avalon in this repository. I've also been known to make my full AXI model available to Patreon sponsors of my blog.

As an experiment, I tried a formal first approach using u/ZipCPU's faxil_slave.v.

I then moved on to an internal desk check of the design ... 1. skydivertricky is right: AXI does not allow timeouts. If you implement an AXI timeout, you will risk crashing any system using your design. Your timeout implementation is therefore broken, and will risk crashing any system attempting to interact with your design. This applies to both your read and write paths. 2. Sure enough, your write state machine looks only for the write address strobe during the idle state. If write data shows up early, the write data will be forgotten causing the system to hang. This was one of the bugs caught by SymbiYosys and mentioned above. 3. Your design has a nasty sequencing bug within it: wren is set on the clock _after the transaction takes place. As a result, the s_axi_awaddr and s_axi_wdata values used within your design may contain garbage within them. Indeed, they may be already set for the next transaction, or the master may put some other value in them. As a result, writes to your design may work for some masters, or more likely will not work at all. (They won't work with any of my own open source AXI-lite masters.) 4. I would recommend implementing WSTRB. There are plenty of implementations out there that will use this value, particularly when crossing from one bus width to another, but also when the CPU attempts to write less than a full word. I've been burned more than once by acting on a write when WSTRB was zero. 5. As predicted by SymbiYosys, your read data calculation is also broken. Specifically, it depends upon the value in ARADDR on the cycle following the cycle where ARVALID && ARREADY. This breaks protocol, and is likely to give you some very unexpected results. 6. While not technically broken, I would recommend that your reads ignore the bottom two bits of address. If you do this, the reads will then work if the CPU issues a load-byte or load-halfword instruction. The same applies to the writes--you should be looking at all but the bottom two bits (for a bus with 32-bit data words, like AXI-lite).

Can a FIFO be generated to use the AXI stream protocol? Absolutely! Check out this FIFO: - S_AXIS_VALID can be fed to the write port, i_wr - S_AXIS_READY is the compliment of the FIFO full output, o_full - S_AXIS_DATA can be fed to the incoming data port, i_data - M_AXIS_VALID is the compliment of the FIFO empty output, o_emtpy - M_AXIS_READY can be fed directly to the read port, i_rd - M_AXIS_DATA can be read directly from the outgoing data port, o_data - If you want to support other AXI Stream signals, they can simply be concatenated with the data signals above.

I recently connected my own IP to a Microblaze core via the AXI-lite interface. Vivado has a tool to generate AXI IP, but it's broken so I used this implementation of an AXI-lite slave. It comes with some registers that'll be accessible in the processors address space. Here is a more detailed explanation of the linked implementation.

Here's an example of an FWFT FIFO written in a vendor independent fashion. Yes, it requires a bit of wizardry to get right--primarily in how the read address is calculated, but I've used it for years now and it's held up nicely for me.