R-tile TX interface unclear. readyAllowance=? readyLatency=?

[alexislms]

R-tile user-guide: https://www.intel.com/content/www/us/en/docs/programmable/683501/22-2-6-0-0/streaming-tx-interface-tx-st-ready-o.html

> Refer to the Avalon® Interface Specifications for a detailed definition of readyLatency. 

https://www.intel.com/content/www/us/en/docs/programmable/683091/20-1/data-transfer-with-backpressure.html

The behavior doesn't seem to be called readyLatency.

• What is the value of readyAllowance and readyLatency of this interface?

> The application must not deassert tx_st_valid_i between tx_st_sop_i and tx_st_eop_i on a ready cycle unless there is backpressure from the R-tile PCIe IP indicated by the deassertion of tx_st_ready_o.

What does that mean? deassertion of tx_st_ready_o including the readyAllowance? Example?

[skbeh]

Hi
readyLatency and readyAllowance have different definition.
Kindly refer to Table 18 of Avalon® Interface Specifications:
https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/st-interface-properties.html

For a better example and illustration between readyLatency and readyAllowance, you can refer to Figure 27 of Avalon® Interface Specifications:
https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/data-transfers-using-readylatency-and.html

[alexislms]

As explained, the documentation is mixing both.
Please provide the exact value for both of them.

Regards,

[skbeh]

It does not follow a fixed latency value between the tx_st_ready_o and tx_st_valid_i signals. 

Data can be received any time within the value as specified by the Avalon Interface Specifications.

[alexislms]

Could you please read again my question and the R-tile doc?

Once more, the R-tile doc is mixing both and is very unclear.

It says readyLatency but what is shown on the diagram is readyAllowance.

---

The application must not deassert tx_st_valid_i between tx_st_sop_i and tx_st_eop_i on a ready cycle unless there is backpressure from the R-tile PCIe IP indicated by the deassertion of tx_st_ready_o. For the definition of a ready cycle, refer to the Avalon Interface Specifications.

---

What does that mean? the real tx_st_ready_o signal or it must not deassert the valid between sop and eop considering the readyAllowance?

The R-tile documentation is too confusing and seems wrong on the terms that are used.

I don't understand the purpose of making it so complicated, why not generating the correct ready signal for good instead?!

[skbeh]

I agreed with you that the R-tile user guide has some mistake.

The timing diagram in Figure 31 of R-tile user guide named the 3 cycles between Ready deassertion until Valid deassertion as 'readyLatency', in fact it is defined as 'readyAllowance' in the Avalon Interface Specs.

I can feedback this mistake to internal Documentation team for correction. 

[alexislms]

Could you tell the value of each one and answer on the deassertion of the valid?

[skbeh]

R-tile user guide, section 4.3.1.4. Avalon Streaming TX Interface:

"This interface does not follow a fixed latency between the pX_tx_st_ready_o and pX_tx_stN_dvalid_i signals as specified by the Avalon Interface

Specifications."

It means data can be received any time within the value as specified by the Avalon Interface Specifications.

readLatency: 0-8

readyAllowance: 0-8

[alexislms]

I'l confused because the doc says:

The maximum latency between the deassertion of tx_st_ready_o and tx_st_valid_i is 16 cycles.

0-8 or 0-16?

It's still unclear about the deassertion of the valid between sop and eop. Can I deassert the valid within the readyAllowance or should I continue until the max (16)?

[skbeh]

There is a note on page 87 of R-tile user guide says:

"Note: This is an additional requirement for the R-tile PCI Express IP core that does not follow the Avalon-ST standard."

So, although Avalon Interface Spec defined 0-8, the R-tile IP accepts readyAllowance up to 16 cycles as it does not follow the Avalon-ST standard.

Q: It's still unclear about the deassertion of the valid between sop and eop. Can I deassert the valid within the readyAllowance or should I continue until the max(16)? 

A: Yes, you can deassert the Valid within the readyAllowance without waiting 16 cycles. An example, in Figure 27 of Avalon Interface Spec, in cycle#9 the Valid is deasserted then re-asserted, data D6 and D7 still can be captured (in this case, since readyAllowance=2, it means two more cycle transfers are allowed after ready deasserted).