Maximum bandwidth of inter-core xCONNECT on an L16

[ers35]

The document XS1-L Link Performance and Design Guidelines details xCONNECT Link bandwidth limitations.

See section Data Rates.
A 5 wire streamed link is listed as having a raw data rate of 250 Mbits/sec. An XS1-L16-128-128QFN has four internal links which connect two XS1-L8-64.

See section XS1-L16-128 System Topologies.
If the raw data rate for a 5 wire streamed link is 250 Mbits/sec, and the L16 has four links, why does the document say "The L16 device thus offers 122Mbits/second inter-core bandwidth within the L16 module."? How is the 122Mbits/second figure calculated?

I did a quick test with a G4, which also has four internal links, and I see a rate of at least 500 Mbits/second between two tiles.

[segher]

The table shows an _effective_ data rate of 250Mbps, for
a symbol time of 7.5ns. Raw data rate is somewhat higher.

You set the symbol delay and token delay for your link, usually
in your XN file. For the internal links of an L2 you can use
"0,1", which is the minimum allowed; symbol time is symbol
delay plus two cycles, and inter-token time is token delay plus
one, so both are two cycles, i.e. 4ns with a 500MHz system
clock.

That gives 20ns for a token, so 50MBps (400Mbps) raw bandwidth,
which agrees with experiments.

I have no clue where that 122Mbps number comes from,
it makes no sense at all. You have four links between the
switches, and you can also count both directions for "total"
bandwidth, but I see no way to get a number that looks in
the least like 122 :-)

The interconnect of a G4 is different: all cores connect (via
processor links, which are 32 bits and run at the system clock)
to one big switch, so you get a lot more inter-core bandwidth.

[ers35]

The attached program counts the number of bytes received over the four internal xCONNECT links on an XS1-L8A-128-QF124-C10 in one second.

To compile and run:

Code: Select all

xcc -O3 -fschedule -report link-speed-test.xc link-speed-test.S XR-AVB-LC-BRD.xn
xgdb a.xe
connect
run
info registers r6 # number of bytes received in one second

Here are the results at various clock rates:
Edit: I forgot to adjust the timer to be based on the actual reference clock rather than 100 MHz. The 125 and 62.5 MHz results below do not make sense. I need to re-do the test, making sure to use PLATFORM_REFERENCE_MHZ instead of 100000000. The 100 MHz results should be correct.

100 MHz ref, 400 MHz system, 25 MHz oscillator: 200000032 bytes = 1.49 gigabits/second
125 MHz ref, 500 MHz system, 25 MHz oscillator: 200000032 bytes = 1.49 gigabits/second
100 MHz ref, 500 MHz system, 25 MHz oscillator: 250000032 bytes = 1.82 gigabits/second
62.5 MHz ref, 500 MHz system, 25 MHz oscillator: 400000032 bytes = 2.98 gigabits/second

[ers35]

How is the 122Mbits/second figure calculated?

122 Megabytes/second = 976 Megabits/second, or roughly the expected figure. The document incorrectly uses Mbits/second instead of MB/second.

[TSC]

The documentation "XS1-L Link Performance and Design Guidelines" contains the following table.

Code: Select all

Link Mode         Header    Data Rate
2w Packetized     1 byte    87 Mbits/sec
5w Packetized     1 byte    217 Mbits/sec
2w Streamed       1 byte    100 Mbits/sec
5w Streamed       1 byte    250 Mbits/sec

Should the values be changed to MBytes/sec?

[segher]

Eric runs four links in parallel, and at roughly twice the speed
used for that table. So it all agrees :-)

[ers35]

The documentation "XS1-L Link Performance and Design Guidelines" contains the following table.

Code: Select all

Link Mode         Header    Data Rate
2w Packetized     1 byte    87 Mbits/sec
5w Packetized     1 byte    217 Mbits/sec
2w Streamed       1 byte    100 Mbits/sec
5w Streamed       1 byte    250 Mbits/sec

Should the values be changed to MBytes/sec?

The unit Mbits/sec is correct in Data Rates. The unit Mbits/second is incorrect under each System Topologies section.

[sethu_jangala]

The unit Mbits/sec is correct in Data Rates. The unit Mbits/second is incorrect under each System Topologies section.

I have raised this as an issue internally and this will be fixed in the documents. Thanks for letting us know.

Sethu.