For Avalon-ST interfaces, one "beat" is the transfer of a single word of data - where one word is equal to "Number of Symbols" times "Symbol Width" bits of data.
"Symbol Width" is basically the size of your base unit of data - for example if it were bytes, it would typically be 8-bit. If you had a 12-bit ADC then your symbol would be 12-bit.
In typical use cases, one beat is equivalent to one clock cycle, as that is the timing interval. So a typical interface will have one beat per cycle.
The additional parameter "Beats per Cycle" allows setting the interface such that more than one beat of the interface can be performed in the same clock cycle.
Based on reviewing the TCL file for the Sink BFM, this is acheived by effectively multiplying the width of the data bus, the valid signal, and all of the packet/error/empty signals, by the number of beats per cycle. The only signal that is not increased in width is the ready signal.
You can think of it like having multiple independent Avalon-ST interfaces all sharing a common ready signal and thus running concurrently.
Having said that, the more definitive source of information is described in the Avalon Interface Specifications document. The table of interest is as shown below:
In this document it states that it is only the data width that is increased, but not the valid/sop/eop signals. However, this disagrees with the TCL file for the BFM. Either the IP core is wrong or the document is wrong. Fortunately as the document states it is a rarely used parameter, and one I hadn't come across before researching this answer.
Based on past experience with Altera/Intel IP core definitions, it is likely that it is the BFM which is wrong (I've come across many such discrepencies in various different IP cores!).
