The Avalon Interface spec is exactly what you are looking for.
Part of the beauty of Qsys is that the components use standard interfaces to communicate. There are 3 main types (ignoring clock, reset and irq for the moment):
avalon-mm The first is the Avalon Memory Mapped Interface. This is a way of accessing different blocks as if they are memory. You have masters and slave devices.
The slave devices behave as if they are memory - so on-chip memory for example has a memory-mapped interface, so do the SDRAM controllers. But more than that, if you have a controller with configuration or status space, then it would make sense to use Av-MM for this too as you can organise the registers into a series of addressable words which starts to resemble a memory bank.
The master devices are things like NIOS CPUs, DMA Controllers, etc. that need to be able to read from slave devices to control the system and move data around.
There are several key signals to this (all of which are described in the interface spec):
<--- Read Data
---> Write Data
---> Address
Then others for flow control, byte enables, etc. (many of which are optional).
Masters can control multiple slaves, and equally slaves can be controlled by multiple masters (Qsys automatically adds the arbitration logic). To make this work, when you connect them in Qsys, each slave is mapped to an address within the masters address space - for example if you had two 4kB memory blocks, one could be assigned 0x0000 to 0x0fff, and the other 0x1000 to 0x1fff - in this case the master would need at least 13bits of address width to access the full range of addresses. Clearly, slave address ranges cannot overlap within a masters address range, otherwise writes to one slave would go to the other as well.
avalon-st The second interface is the Avalon Streaming interface. This is a way of transferring large amounts of data around a system quickly. In this case you have a Source and a Sink. Data flows out of the source into the sink.
The beauty of this approach is you don't have the overhead of having to issue an address to a slave and wait for a response like in the Avalon-MM. Instead the sink doesn't care about addresses, it doesn't need to know where the data is coming from, just how fast it is coming in, and which clock cycles contain valid data.
Streaming devices have several key signals (the ones marked opt are optional):
<--- Ready (opt)
---> Valid (opt)
---> Empty (opt)
---> Data
Data is obvious, that is just what you want to send. But it could have different formats - so the interface needs to specify for example what is the symbol size (e.g. 8 bits) and how many symbols are received in one clock cycle. For example if you had a 16bit data bus, but were sending 8bit symbols, you could pack 2 in the same clock cycle.
If there is more than one symbol per beat (clock cycle), then you may want to also tell the sink that some symbols are empty. If say you can send 8 symbols per beat, but only have 4 to send, then there are 4 'empty' spaces in the data bus this clock cycle.
Ready and Valid are flow control signals. Valid comes from the source to say in the current clock cycle there is valid data. Ready is the only signal back from the sink to say whether or not it is ready to receive data. If these two signals are present, then data is only considered sent in clock cycles where it is both valid and the sink is ready.
Streaming interfaces are typically used where you need to transfer a data stream such as Ethernet packets or data from any sequential source where an address is meaningless. The great thing about these is you can build blocks to process the data on the fly.
For example if you have an ADC which is spewing out samples - no address for an ADC is there? - then you could use Av-ST and have a block which could say convert the sample to a floating point number. In this case data would come in, be converted, and go out in a pipelined fashion. Streaming is basically like water flowing through pipes.
conduits These are used in cases where neither of the above fit - e.g. if you have a block which has a initialised status output. This could use a conduit which could for example be routed to a physical pin where an LED is connected.
They are used for so called side band signals - other information about a controller which may need to be constantly monitored by other controllers (e.g. enable signal?).
others There are other signals like Clocks, Reset signals, etc. most of which are self explanatory.
So essentially as you are building your own modules, try to use standard Qsys interfaces that way in you can just plug them together in Qsys with other modules and IP cores. The only thing you need to learn then is the signalling patterns of these interfaces. After than consult the data sheets for IP cores to see how they are using each interface.
Honored Contributor
