Altera Avalon ST packet transfer

[shaiko]

Hello,

The Avalon ST bus has a "channel" signal that denotes the required recipient.

https://www.altera.com/content/dam/...US/pdfs/literature/manual/mnl_avalon_spec.pdf

My question:
Can this value change during a packet transfer?
Or once a packet transfer starts it must end before changing the channel?

 

[K-J]

Avalon defines channel as the channel number for data being transferred on the current cycle. It is not listed as a 'packet transfer' signal which would mean that channel can change on every cycle not just at the start of a packet.

However, whether or not a source should change channel will be defined by whether the sink device supports it.

Kevin

 

[shaiko]

K-J,

Can you explain the benefits of using a packet transfer vs a simple transfer over the ST bus.
From the waveforms in the spec, it seems like both are capable of the same throughput - so why/when should we use the packet mechanism ?

 

[TrickyDicky]

Some things use packets, some are just raw data. For example, transferring ethernet over Avalon would require packet transfers, but rs232 would just be data. So it depends on the application.

 

[shaiko]

For example, transferring ethernet over Avalon would require packet transfers

Because with RS232 the Tx size is fixed while with Ethernet the size can vary and you have to know it before sending?

 

[TrickyDicky]

Avalon is just a conduit. It offers features that make it suitable for all types of data transfer. Packetised or not, it's basically the same. With packets you just get the extra eof and sof signals. Otherwise its identical.

It's very similar to axi streaming, but much less supported.

 

[shaiko]

Another thing:
The more I look into it - the more it seems that you must use "look-ahead" FIFO's with unregistered output to implement this bus.

Do you agree?

 

[TrickyDicky]

It depends on the ReadLatrncy parameter. But yes, look ahead is pretty much a requirement.

Altera does have an Avalon st FIFO block ( you'll have to generate it from qsys though)

 

[shaiko]

As far as you understand - are packet transfers over the ST bus permitted with a ready latency higher then 0 ?

 

[TrickyDicky]

Yes. For example, the srio core has a readyLatency value of 1.

 

[shaiko]

TrickyDicky,

Section 5.9 - Data Transfer with Backpressure
First paragraph:

The sink asserts ready for a single clock cycle to indicate it is ready for an active cycle.

Why "single clock cycle"?
Later see that the number of ready cycles depends on the readylatency parameter...

 

[ads-ee]

Look at the figures following this section 5.9 text. The ready goes active for at minimum 1 clock cycle, it stays active for the duration of the transfer.

I also think the drawings are inconsistent in the de-assertion of ready in the various cases. You might have to run simulations on some example designs to actually understand the real behavior.

This is one very good reason to NOT use this idiotic Altera only junk bus. Only an Altera IP core that support this bus is likely to work given the spec is so poorly written.

 

[shaiko]

Look at the figures following this section 5.9 text. The ready goes active for at minimum 1 clock cycle, it stays active for the duration of the transfer.

I have been looking at them for many many minutes - trying to correlate them to the explanations. My frustration grows with every ready cycle...

 

[ads-ee]

I really hope you aren't stuck using this PO_ bus because of something like this.

 

[K-J]

TrickyDicky,

Section 5.9 - Data Transfer with Backpressure
First paragraph:


Why "single clock cycle"?
Later see that the number of ready cycles depends on the readylatency parameter...

The reason for 'single clock cycle' is that 'ready' is only indicating that it is ready for a single clock, not ten clock cycles (as an example). It may turn out that on ten consecutive clock cycles, it turns out to be 'ready', but it will make that determination over a period of ten clock cycles. It will not indicate that it is ready for ten clock consecutive clocks all at once.

Kevin

 

[shaiko]

I really hope you aren't stuck using this PO_ bus because of something like this.

Not this time. In my case I have to design a generic bus controller to interconnect with a 3rd party IP core.
The thing is - this 3rd party core is also in the makings (no simulation model)...so I can only hope that their designers take the extra effort to disambiguate the spec and reach the same technical conclusions as I have.

 

[TrickyDicky]

If it were me - I would stick a FIFO in their interface then make everything else AXI (thats what we did!)

 

[shaiko]

If it were me - I would stick a FIFO in their interface then make everything else AXI (thats what we did!)

Stick it in what part of the interface?
Can you elaborate please...

Using a FIFO is essential for feeding Tx data when you're source and registering incoming data when you're sink.
Are these the FIFOs you're referring to?

 

[TrickyDicky]

Avalon has the readyLatency parameter, AXI does not. So axi can plug straight into a lookahead fifo. With avalon, you have to use a FIFO and connect ready to "almost_full" from a FIFO, and set the almost full threshold depending on the readLatency Avalon parameter. In AXI, valid just connects directly to empty.

Heres the FIFO I had that converted Avalon St to AXI:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
rx_fifo_wr_data(69 downto 66)  <= rx_tkeep_gen;
rx_fifo_wr_data(          65)  <= rx_av_st_eop;
rx_fifo_wr_data(          64)  <= rx_av_st_sop;
rx_fifo_wr_data(63 downto  0)  <= rx_av_st_d;
                                  
rx_av_st_ready      <= not ( rx_fifo_almost_full );
                                  
rx_fifo_inst : scfifo
generic map (          
   lpm_width                => 70,
   lpm_widthu               => 2,
   lpm_numwords             => 4,
   lpm_showahead            => "ON",
   almost_full_value        => 3,
   intended_device_family   => "STRATIXIV"
)
port map (
    clock           => clk, 
    sclr            => sreset,
    
    data            => rx_fifo_wr_data,
    wrreq           => rx_av_st_valid,
    full            => rx_fifo_full,
    almost_full     => rx_fifo_almost_full,
    
    rdreq           => rx_axi4s_tready,
    empty           => rx_fifo_empty,
    q               => rx_fifo_rd_data
);
 
rx_axi4s_tvalid <= not rx_fifo_empty;

---

There is no requirement to put a FIFO on an Avalon Interface, but the readyLatency paramter makes life a pain.

 

[shaiko]

As I see it the ST is designed for moving chunks of data between functionality asynchronous system componemts.

Even with the readylatency set to 0 - using a FIFO is very natural for this interface...
Do you agree?