Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Altera Avalon ST packet transfer

Status
Not open for further replies.
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
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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 ?
 

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.
 

For example, transferring ethernet over Avalon would require packet transfers
Click to expand...
Because with RS232 the Tx size is fixed while with Ethernet the size can vary and you have to know it before sending?
 

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.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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?
 

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)
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
As far as you understand - are packet transfers over the ST bus permitted with a ready latency higher then 0 ?
 

Yes. For example, the srio core has a readyLatency value of 1.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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.
Click to expand...
Why "single clock cycle"?
Later see that the number of ready cycles depends on the readylatency parameter...
 

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.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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.
Click to expand...
I have been looking at them for many many minutes - trying to correlate them to the explanations. My frustration grows with every ready cycle...
 

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

shaiko said:
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...
Click to expand...

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
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
I really hope you aren't stuck using this PO_ bus because of something like this.
Click to expand...

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.
 

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

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
If it were me - I would stick a FIFO in their interface then make everything else AXI (thats what we did!)
Click to expand...
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?
 

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.
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
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?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top