add MGT_SMA DRTIO link #143

New Issue

sb10q · 2021-10-08T16:09:49+08:00

sb10q commented

2021-10-08 16:09:49 +08:00

There is no content yet.

mwojcik was assigned by sb10q

2021-10-08 16:09:49 +08:00

mwojcik commented

2021-10-13 10:00:32 +08:00

This is only relevant to zc706, as I cannot find MGT_SMA for kasli-soc, right?

Anyway, this should be solved already: https://git.m-labs.hk/M-Labs/artiq-zynq/src/branch/master/src/gateware/zc706.py#L175

Just in case some testing is in order.

This is only relevant to zc706, as I cannot find MGT_SMA for kasli-soc, right? Anyway, this should be solved already: https://git.m-labs.hk/M-Labs/artiq-zynq/src/branch/master/src/gateware/zc706.py#L175 Just in case some testing is in order.

sb10q commented

2021-10-13 10:41:59 +08:00

Poster

Correct, Kasli-SoC doesn't have those SMAs.

sb10q commented

2021-10-13 10:43:30 +08:00

Poster

We can test between two ZC706 or ZC706/KC705 with SMA cables, but this is low-priority, we can test it later.

mwojcik commented

2021-11-22 16:46:22 +08:00

The link itself is confirmed working - had to disconnect the SFP and change the order in the gateware file (note: having both SMA and SFP connected at the same time seems to be confusing for both devices, since one port is drtiosat, the other is drtiorep - and with the rep both sides are trying to send an echorequest and get an echoreply, and thus it wouldn't move onto the other link that would be actually working).

e.g. output:

[  5262.933016s]  INFO(runtime::rtio_mgt::drtio): [LINK#1] link RX became up, pinging
[  5270.121700s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] ping failed
[  5287.126041s]  INFO(runtime::rtio_mgt::drtio): [LINK#1] link RX became up, pinging
[  5293.799055s]  INFO(runtime::rtio_mgt::drtio): [LINK#1] remote replied after 33 packets
[  5317.929827s]  INFO(runtime::rtio_mgt::drtio): [LINK#1] link initialization completed
[  5317.971241s]  INFO(runtime::rtio_mgt::drtio): [DEST#2] destination is up
[  5317.976613s]  INFO(runtime::rtio_mgt::drtio): [DEST#2] buffer space is 128
[  5318.183119s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] error(s) found (0x03):
[  5318.188932s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] received packet of an unknown type
[  5318.197094s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] received truncated packet

Side note:

There's an issue that may be related to this one - when ZC706 (master) was tested with Kasli, I got CRC errors everywhere, with the solution being flipping byte order within 4-byte words except the checksum. This is not the case when communicating with the KC705, and I had to revert that change, flipping exactly nothing on both receiving and transmitting ends.

The link itself is confirmed working - had to disconnect the SFP and change the order in the gateware file (note: having both SMA and SFP connected at the same time seems to be confusing for both devices, since one port is drtiosat, the other is drtiorep - and with the rep both sides are trying to send an echorequest and get an echoreply, and thus it wouldn't move onto the other link that would be actually working). e.g. output: ``` [ 5262.933016s] INFO(runtime::rtio_mgt::drtio): [LINK#1] link RX became up, pinging [ 5270.121700s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] ping failed [ 5287.126041s] INFO(runtime::rtio_mgt::drtio): [LINK#1] link RX became up, pinging [ 5293.799055s] INFO(runtime::rtio_mgt::drtio): [LINK#1] remote replied after 33 packets [ 5317.929827s] INFO(runtime::rtio_mgt::drtio): [LINK#1] link initialization completed [ 5317.971241s] INFO(runtime::rtio_mgt::drtio): [DEST#2] destination is up [ 5317.976613s] INFO(runtime::rtio_mgt::drtio): [DEST#2] buffer space is 128 [ 5318.183119s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] error(s) found (0x03): [ 5318.188932s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] received packet of an unknown type [ 5318.197094s] ERROR(runtime::rtio_mgt::drtio): [LINK#1] received truncated packet ``` Side note: There's an issue that may be related to [this one](https://github.com/m-labs/artiq/issues/1779) - when ZC706 (master) was tested with Kasli, I got CRC errors everywhere, with the solution being flipping byte order within 4-byte words except the checksum. This is not the case when communicating with the KC705, and I had to revert that change, flipping exactly nothing on both receiving and transmitting ends.

sb10q closed this issue

2021-11-22 16:48:48 +08:00

Sign in to join this conversation.