Avalon_ mm_ master wrapper (vhdl)

Look here:

http://www.altera.com/support/examples/exm-list.jsp?cat=embedded

Refer to the Avalon-MM Slave and/or Master Templates.

Wrapping your component to a MM-slave is easy: simply connect your PI and output ports to the user_data* registers.

A MM-Master is a bit more complex.

Dear Cris72,

i saw that earlier itself, but the template is in verilog , i am not that much familiar with that code.is there any template in VHDL format sir.

main aim of my code is to reduce the No.of lines in required in avalon BUS. So output from NIOS is 32-bit.. i am reducing to 16-bit using CDMA. here i have to connect the output from NIOS to CDMA_Encoding. (32-bit-->16bit), Is this possible to do so.

Is there any ready made codes which work as a wrapper.

Thank you.

You really want to leave the interface as 32bit, ignore the high bits on writes and return zeros for reads.

A 16bit Avalon slave requires a bus width adapter (so the 32bit nios master can access it).

Sir,

Could you elaborate your previous reply.

and also please tell me write (from where to where,nios to IP or IP to nios), similarly read(from where to where). i am very much confused.

Thankyou.

The nios cpu always does 32bit bus cycles, when it does read cycles all 4 byte enables are always asserted - this is independant of the implied data width of the instruction.

If your avalon slave only has 16 data lines then a 'bus width adapter' is transparantly added to the avalon switch fabric by the sopc builder/qsys.

This will generate two cycles into your 16bit slave for every access requested by the nios cpu. The write cycles will have appropriate byte enables asserted (possibly none of them), the reads will always have both byte enables asserted.

--- Quote Start ---

Hello,

In my system , the output from NIOS-II processor will be given to CDMA_Encoding(it encodes 32-bit data from NIOS-II and convert it to 16-bit data) and then given to avalon interface. Similarly from avalon interface i will get 16-bit data,which is given to CDMA decoding( it again converts 16-bit data into 32-bit,as original output from NIOS-II) and then given to slave(like SDRAM or Flash Memory).

NIOS-->CDMA_ENCODING-->AVALON-->CDMA_DECODING-->SLAVE.

this is the flow of system.

--- Quote End ---

First you'll need to decide whether the input and output interfaces of CDMA Encoding and Decoding should be 'pulled' or 'pushed' through the pipeline. This will determine if that interface is a 'master' or 'slave' interface in Avalon jargon.

An example of 'pushing' would be the encoding block simply outputs data when it has it available to send and it is expecting the receiver to catch it. In your example, you simply listed what looks to be the data path signals 'PI' and 'Output', but there are no signals to indicate when data is actually valid. An example of 'pulling' would be if the decoding block decided when it was ready to receive data from the upstream block which was then expected to supply the data.

To get a bit more concrete, you will have to look at each interfaces and decide based on your design which implementation is easiest to accomplish. The only hard and fast rule is that a 'master' talks only to a 'slave'; 'master' do not talk to each other, nor do 'slaves'. Every transfer is initiated by the 'master' and acted on by the 'slave'.

Here is your data flow

NIOS-->CDMA_ENCODING-->AVALON-->CDMA_DECODING-->SLAVE

And here I've pencilled in a possible implementation where (M) indicates the interface is a 'master', (S) indicates a 'slave'. Note that encoding and decoding blocks each have an input and an output interface.

NIOS-->(S)CDMA_ENCODING(M)-->(S)CDMA_DECODING(M)-->(S)SLAVE

or perhaps this, assuming that the output to what you called 'SLAVE' is not Avalon

NIOS-->(S)CDMA_ENCODING(M)-->(S)CDMA_DECODING-->SLAVE

Your other choice could be for the Avalon interface between the CDMA blocks could also be:

NIOS-->(S)CDMA_ENCODING(S)-->(M)CDMA_DECODING-->SLAVE

Again, whether you choose the connections between the two CDMA blocks is somewhat arbitrary, do what is convenient for you. The Avalon fabric will stitch together the 'master' to 'slave' logic, but you need to provide the 'master' and the 'slave'.

Once you have the flow control defined, then you look at the Avalon manual. Assuming you chose the following flow

NIOS-->(S)CDMA_ENCODING(M)-->(S)CDMA_DECODING-->SLAVE

Then then CDMA_ENCODING block is a master and is pushing data out to a slave. This means the following:

- CDMA_ENCODING needs to provide a 'write' and 'writedata' signals as outputs, and 'waitrequest' as an input.

- CDMA_DECODING needs to provide 'chipselect', 'write' and 'writedata' signals as inputs and (optionally) provide 'waitrequest' as an output.

If you refer to the Avalon manual it actually is pretty clear about what the signals definitions are, but you need to know what type of interface is needed and understand that each of the connections you show in your flow diagram represent interfaces.

It's actually not that hard once you get the first one or two under your belt and Avalon does provide a simple low overhead flow control mechanism that is almost always needed since there are very few cases where something can simply blast out data and expect something to be able to receive and process it on every clock cycle from here to eternity. Even if you were simply writing something to memory, a memory controller would always have to pause on occasion to generate a refresh to the memory device...which implies that something that is shoving data at it would have to pause as well which implies there has to be some signalling for data flow control.

Kevin Jennings

Dear Kevin Jennings,

once i try your sugessions, i will get back to you.

thank you very much.

Dear Sir, When should we assert these signals.

1.read---> if "read=1" , generally what should happen,it reads read address . am i right?

2.write---> if "write=1"writes into some write address.

but i have a doubt in these following control signals:

1.readwaittime

2.readdatavalid

3.waitrequest

please tell something about these three signals correctly.what should happen ,when we assert which signals.

thanks in advance.

--- Quote Start ---

Dear Sir, When should we assert these signals.

1.read---> if "read=1" , generally what should happen,it reads read address . am i right?

2.write---> if "write=1"writes into some write address.

but i have a doubt in these following control signals:

1.readwaittime

2.readdatavalid

3.waitrequest

please tell something about these three signals correctly.what should happen ,when we assert which signals.

thanks in advance.

--- Quote End ---

It appears that your understanding of read, write and address are correct, but let me re-state just in case:

- Read is an output of a master that indicates that it wants to read from 'address'. 'Read' is an input to a slave.

- Write is also an ouput, but indicates that the master wants to write to 'address'. 'Write is an input to a slave.

For waitrequest, imagine you have the case where the slave for some reason cannot immediately respond to a read or a write. Maybe it takes a fixed number of clock cycles, or maybe it varies. Now ask yourself, how does the master know that the slave cannot respond on that clock cycle? The answer is provided by the waitrequest signal which is (optionally) an output of a slave and a required input to a master. Inside the master, a 'write' completes when the 'write' output is '1' and the 'waitrequest' input is '0'. In the situation I described, the slave should be asserting waitrequest to a '1' until the clock cycle when it finally accepts the 'read' or 'write' command. Whenever waitrequest is '1', the master must not change the state of 'read', 'write', 'address' or 'writedata'.

The signal 'readdatavalid' I'll hold back on for now and simply say that this signal is used when the master and slave are capable of queueing up read commands and providing the data later but still allowing commands to be issued on each clock cycle (unlike when waitrequest is set to 1). Since you're just starting on Avalon and you're designing your own interface, my guess is that you can likely get away without the need for 'readdatavalid' at this time. Get the basics of 'read', 'write' and 'waitrequest' down first.

readwaittime is not a signal, but it is a property. The definition per the Avalon spec is:

for interfaces that don’t use the waitrequest signal, readwaittime indicates the number of cycles or nanoseconds before the slave accepts a read command.

What this means is that let's say you design some widget and you can read from that widget on some interface. But you can't accept new read commands on every clock cycle. Per the earlier discussion, this would mean that the slave should assert waitrequest until it actually can provide the data. SOPC Builder/Qsys allows an Avalon slave device designer to be lazy, not provide any explicit waitrequest output but just tell it (via the readwaittime property) how many clock cycles to wait for data to be valid. Then when SOPC Builder/Qsys generates the logic for the interconnect it will generate the counter to keep track and send a waitrequest signal to the master for 'readwaittime' clock cycles, even though the slave didn't even have a 'waitrequest' output. Like I said, it's for the lazy guy who doesn't want to specify in their own code the correct behavior. It also means that such a slave device is only useful with SOPC Builder/Qsys since the slave device designer is counting on someone else (i.e. SOPC/Qsys) to generate the wait clock logic.

Kevin Jennings

--- Quote Start ---

- Read is an output of a master that indicates that it wants to read from 'address'. 'Read' is an input to a slave.

- Write is also an ouput, but indicates that the master wants to write to 'address'. 'Write is an input to a slave.

--- Quote End ---

By the way, there is an equally valid interpretation that says

- The 'read' output of a 'master' is equivalent to a data 'sink' indicating that it is 'ready'. The 'waitrequest' output of a slave can be thought of as the logical not() of a data 'valid' signal from a data 'source'.

- The 'write' output of a 'master' is equivalent to a data 'source' indicating that data is 'valid'. The 'waitrequest' output of a slave can be thought of as the logical not() of a data 'ready' signal from a data 'sink'.

The signals 'ready' and 'valid' are what Avalon uses for what it calls an 'ST' (streaming transfer) interface which consists of data 'sources' and data 'sinks'. Sometimes this view of things is easier to get a handle on, but logically they are bascially interchangable. Given that, the one advantage of an Avalon master is that it can be both a reader and a writer, but a streaming transfer can only be one...however a widget can simply have two ST interfaces to accomplish the same feat.

Kevin Jennings