SoC+fpga, over AXI, AMBA bus

[legacy]

I just like to hear what do you think about AXI, and what is your experience with linux (if the SoC, e.g. ARM-core based, can run linux) 

[legacy]

just to provide an example from the real world
the DE1 board has the SoC===AXI===fpga working scheme

[legacy]

amba - Advanced Microcontroller Bus Architecture (AMBA) is a protocol for the management and interconnection in a System-on-Chip (SoC). A SoC is a single chip that contains many or all essential components of a computer in one chip. The AMBA drivers in this folder allow the kernel to run on these chips.

edit:
I add this slideshow

[ataradov]

I just like to hear what do you think about AXI

Well designed bus. Other than this, what else to say? It is a bus and it serves its stated purpose.

and what is your experience with linux (if the SoC, e.g. ARM-core based, can run linux) 

It just works, and there are really no other options for general purpose applications.

[legacy]

It just works

how good is the linux support? and what is the most used application scenario?
I have noted that DE1 is using and providing a custom solution, and so it's done by a lot of FPGA+SoC products

and there are really no other options for general purpose applications.

well, it depends, in my case, if I can have the last word in the design, and if I can avoid a SoC like the one used in DE1, I'd rather use the shared-ram approach (between a CPU and an fpga), which is completely different

[ataradov]

how good is the linux support?

The bus itself does not need to be supported by the OS. It just works. Depending on the design there can be some configuration registers exposed, but they are mostly non-essential and default configuration should work just fine.

well, it depends, in my case, if I can have the last word in the design, and if I can avoid a SoC like the one used in DE1, I'd rather prefer the shared-ram approach, which is completely different

If you don't need to run Linux, then don't. I don't see a problem here.

[ataradov]

I don't think AXI is designed to be exposed on external pins. There are way to many signals for that. It is a SoC system interconnect bus.

Typically for communication with [slow] outside devices, you want to put AXI-APB bridge and make your device APB-compliant. APB bus is much simpler and can be exposed reasonably well.

And the brilliance of AXI is that it knows how to handle those slow bridges efficiently without stalling everything.

[legacy]

no doubt, but it is used to connect an fpga to a SoC, or two SoCs together
the point is: when linux is involved, I do not believe it has a good support, as I can't see a stable working scheme
and each vendor seems to add his custom support

and so I'd like to hear about practical experiences: because I have to choose IF to use it, or not
which implies if to stay with SoC+FPGA (more specifically cloning the De1), or not

[ataradov]

no doubt, but it is used to connect an fpga to a SoC, or two SoCs together

Can you show an actual example?

the point is: when linux is involved, I do not believe it has a good support, as I can't see a stable working scheme

I don't understand. AXI is completely transparent to Linux. It is like saying that Linux does not support capacitors in your power supply. Linux just does not care.
 

and each vendor seems to add his custom support

Again, examples? AXI is a specification. Some things there are optional, but you can't add new things and still call it AXI.

and so I'd like to hear about practical experiences: because I have to choose IF to use it, or not
which implies if to stay with SoC+FPGA (more specifically cloning the De1), or not

DE1 is a dev. kit. It can run many projects, which one you are talking about?

[ataradov]

Also, if you are talking about DE1-SoC board, then ARM core there is implemented inside an FPGA and you don't really have a choice on what bus to support. Cortex-A9 has AXI sticking out of it and that's your only option.

As I already pointed out, you can put AXI-APB bridge and make your peripheral to support whatever protocol you feel like, but Cortex-A9 will only talk AXI.

[legacy]

I don't understand. AXI is completely transparent to Linux

say, dedicated kernel modules

[legacy]

DE1 is a dev. kit. It can run many projects, which one you are talking about?

we (my team and I) are evaluating the possibility to use the De1 kit as starting point for a few new products: say, it's currently in use as "prototype"

[ataradov]

say, dedicated kernel modules

I still don't get it. You can have modules for peripherals that sit on a bus. There is no need for a bus module. What it will do exactly?

[ataradov]

we (my team and I) are evaluating the possibility to use the De1 kit as starting point for a few new products: say, it's currently in use as "prototype"

If you are not doing some super high bandwidth applications, chances are, you won't have to touch AXI at all.

[legacy]

excellent 

[Kilrah]

no doubt, but it is used to connect an fpga to a SoC, or two SoCs together

No, it is purely internal to one single chip. Your DE1 board does not connect an SoC to an FPGA, it doesn't even have an SoC next to the FPGA...

It only has an FPGA, within which you can create an SoC by implementing a processor and peripherals into it. If that processor uses an AXI bus to talk to its peripherals then so be it, but it's not something you need to actually care about from a software point of view. Your peripherals will expose memory-mapped registers that you access through a given address, the fact this goes through an AXI bus is transparent, it's just how the hardware does things.

[legacy]

If that processor uses an AXI bus to talk to its peripherals then so be it, but it's not something you need to actually care about from a software point of view. Your peripherals will expose memory-mapped registers that you access through a given address, the fact this goes through an AXI bus is transparent, it's just how the hardware does things.

things like drivers/amba/bus, and I see patches for De1

[legacy]

Your DE1 board does not connect an SoC to an FPGA

yes, it's clear to me, I had forgotten to specify, but I meant "internally", the ARM core is inside the chip, which also contains the fpga, and you can have (in the theory) two SoC plus an FPGA inside the same chip, e.g. two arm cores, plus their peripherals, both of them connected to a fpga over the AMBA bus

so, internally, the SoC is connected to the FPGA over the AMBA bus

[miguelvp]

It doesn't help that Terasic reuses their names, for example there is also the DE0-Nano SoC with dual A9 ARM hard cores on it.
Not to be confused with the DE0-Nano with no hard cores.

[langwadt]

I just like to hear what do you think about AXI

Well designed bus. Other than this, what else to say? It is a bus and it serves its stated purpose.

well designed except for one big thing; there is no timeout

if you try to access a register on the axi bus that doesn't respond, e.g. you haven't configured the programmable logic
the only way out is a hardware reset

[ataradov]

well designed except for one big thing; there is no timeout

If you try to shoot yourself, you will die. Don't access unimplemented registers.

[ataradov]

things like drivers/amba/bus, and I see patches for De1

This is mostly a way to organize devices. It is purely software stuff, it does not interact with actual hardware.

And I think it is a legacy thing (no pun intended), its functionality is replaced by device tree.

[langwadt]

well designed except for one big thing; there is no timeout

If you try to shoot yourself, you will die. Don't access unimplemented registers.

simple enough to say, when the only way to tell is to point the gun at your head and pull the trigger

for example; something simple like loading a different configuration for the programmable logic will require that you kill all programs and unload all drivers that might access the axi bus to that logic
because any access while reconfiguring will end in a lockup that you can only get out off with a hard reset

[langwadt]

things like drivers/amba/bus, and I see patches for De1

This is mostly a way to organize devices. It is purely software stuff, it does not interact with actual hardware.

And I think it is a legacy thing (no pun intended), its functionality is replaced by device tree.

the devicetree just tells what drivers to load and how to configure them

[ataradov]

something simple like loading a different configuration for the programmable logic will require that you kill all programs and unload all drivers that might access the axi bus to that logic

Otherwise you will have to write all your software to be able to deal with timeouts. From a programmer point of view, they will have to look like some value (0?) is returned for reads and writes that go nowhere. That is unless you want to handle exceptions.

All of this is a hell for a programmer. It is much easier to stop accessing locations before they disappear.

Also, ARM implementation of AXI allows you to connect a default slave that handles all unhanded request. Just use that if your implementation allows it.

[ataradov]

the devicetree just tells what drivers to load and how to configure them

Yep, and this "driver" is just an old way of doing the same. It is only used by a few unsupported boards to specify hardcoded hardware configuration.

[langwadt]

something simple like loading a different configuration for the programmable logic will require that you kill all programs and unload all drivers that might access the axi bus to that logic

Otherwise you will have to write all your software to be able to deal with timeouts. From a programmer point of view, they will have to look like some value (0?) is returned for reads and writes that go nowhere. That is unless you want to handle exceptions.

I'd much rated handle a crashed program/driver or exceptions, than a system that hang until someone hits the reset button

All of this is a hell for a programmer. It is much easier to stop accessing locations before they disappear.

I disagree

Also, ARM implementation of AXI allows you to connect a default slave that handles all unhanded request. Just use that if your implementation allows it.

it won't help the problem is not unhanded request it is transactions that never finish

[ataradov]

it won't help the problem is not unhanded request it is transactions that never finish

What do you mean? If your software makes a request that is not handled by any of thew real slaves, this default slave takes over and completes the transaction.

Of your are saying that your slave disappears right in the middle of the transaction? I don't  think this bus is designed to handle this level of dynamic reconfiguration. I don't think any existing bus can do this. That's just stupid to expect that slave can disappear in the middle of the transaction.

[langwadt]

it won't help the problem is not unhanded request it is transactions that never finish

What do you mean? If your software makes a request that is not handled by any of thew real slaves, this default slave takes over and completes the transaction.

Of your are saying that your slave disappears right in the middle of the transaction? I don't  think this bus is designed to handle this level of dynamic reconfiguration. I don't think any existing bus can do this. That's just stupid to expect that slave can disappear in the middle of the transaction.

if the slave disappears during a transaction or isn't there when a transaction is started the system
end up in a a dead lock. Once a master has set xVALID it must wait for xREADY

dynamic reconfiguration is entirely reasonable in a system with configurable logic.
A bus that crashes the whole system waiting forever on something that ought to take microseconds
is silly

[ataradov]

dynamic reconfiguration is entirely reasonable in a system with configurable logic.

You do whatever you want of course, but don't blame the bus that it does no handle devices disappearing in the middle of transaction. That's just bad system design and there is no need to over complicate the bus logic for things that will never happen in actual real life.

[langwadt]

dynamic reconfiguration is entirely reasonable in a system with configurable logic.

You do whatever you want of course, but don't blame the bus that it does no handle devices disappearing in the middle of transaction. That's just bad system design and there is no need to over complicate the bus logic for things that will never happen in actual real life.

that's like saying why bother with protected memory or exceptions it is never going to happen in
real life and if it does it is just bad system design

[legacy]

not brilliant, but it's extremely good, this link shows a bit of the magic under the hood: Exploring the Arrow SoCKit Part III - Controlling FPGA from Software   

[legacy]

Design and Implementation of AMBA-AHB&APB bridge memory controller by VHDL

[legacy]

what is the equivalent of De1 in the Xilinx world ? (SoC/ARM + FPGA, with a bus-bridge in the middle)

[ataradov]

Any board based on Zynq. Prices vary a lot, so pick whatever fits your bill.

[legacy]

yes, I meant within the same price as De1, and … is it this one ?

[ataradov]

http://zedboard.org/ is one of the most famous. There are many variations with wide rage of prices. Community support is there.

The cheapest one is actually a board from Adapteva, but their site seems to be down at the moment.

[Kilrah]

I've got a Zybo, and waiting for my snickerdoodle.
https://www.crowdsupply.com/krtkl/snickerdoodle

Still in preproduction, but it'll be a very cheap entry price.

[legacy]

https://www.crowdsupply.com/krtkl/snickerdoodle]snickerdoodle seems good