AM6442: Disable MAC-side delay through MCU+ SDK

Hi Ryan,

All of the MCU+ SDK examples with R5 (RTOS) will have a standard delay configured by default. In case your board design allows for operating with no delay, you can update the sysconfig with corresponding values, and the application will configure it for you to have no delay. You can find the delay configuration in sysconfig-gui in the following location:

ETHPHY(ENET CPSW/ICSS) > Extended Configuration > Tx/Rx delay in ps

You can adjust the delay at sub nanosecond level.

Can you please let us know why you are looking to remove the delay? By knowing your usecase, we can suggest you any better alternatives if available.

Thanks and regards,
Teja.

We are seeing a ~9.90ns delay between tx clock and tx data from CPU to PHY. Rx clock and data from PHY to CPU is correct at 2ns. Using the following PHY configuration as per the TI examples:

static const Dp83867_Cfg gEnetCpbBoard_dp83867PhyCfg =
{
/* The delay values are set based on trial and error and not tuned per port of the evm */
    .txClkShiftEn         = false,
    .rxClkShiftEn         = true,
    .txDelayInPs          = 250U,   /* 0.25 ns */
    .rxDelayInPs          = 2000U,  /* 2.00 ns */
    .txFifoDepth          = 4U,
    .impedanceInMilliOhms = 35000,  /* 35 ohms */
    .idleCntThresh        = 4U,     /* Improves short cable performance */
    .gpio0Mode            = DP83867_GPIO0_LED3,
    .gpio1Mode            = DP83867_GPIO1_COL, /* Unused */
    .ledMode              =
    {
        DP83867_LED_LINKED,         /* Unused */
        DP83867_LED_LINKED_100BTX,
        DP83867_LED_RXTXACT,
        DP83867_LED_LINKED_1000BT,
    },
};

We have tried with txClkShiftEn set to false and true. Trying to determine the source of the delay coming from the AM6442 side.

I am not seeing the settings you mentioned in Syscfg through CCS, however I think that is covered through our custom board file as shown above. 

Hi,

Yes, this is the configuration I was referring to. Having a 9.9ns delay is higher than expected. Can you please confirm if 'skipExtendedCfg' option is set to false? Are the delay values with txClkShiftEn being true and false same? 

Please provide the PHY register dumps of RGMII Delay Control Register (0x0086), and RGMII Control Register (0x0032). Along with it, can you please provide the information of where exactly are you taking the delay measurements on your board?

Thanks and regards,
Teja.

Yes, skipExtendedCfg is set to false.

Delay values with txClkShiftEn are the same when set to true or false.

We are using linkCfg->speed     = ENET_SPEED_100MBIT; and linkCfg->duplexity = ENET_DUPLEX_FULL;

Test points are R310 and R314, resistors are really close to the driver (less than 100mils).

I will post another update with the PHY register output.

Hi Ryan,

The link config and the skipExtendedCfg looks correct. The behavior with txClkShiftEn looks suspicious. I will try to bring the PHY team experts to support this once we have the register dump available.

Thanks and regards,
Teja.

Hi Teja,

I was able to get access to a better scope and test at gigabit speed with autonegotiate enabled. At the faster speed I was seeing 2ns or less delay between clock and data. Our hardware team was expecting the delay time to be the same at any speed. Do you know if this is a feature of the AM64x that the delay changes based on the speed?

Thanks,

Ryan

Hi Ryan,

The design for the AM64x was done considering 1 Gbps operation in the goal. The default configuration is also calibrated for 1 gig speeds. I have to check with our hardware team to get a better read on the delay behavior in case of 100 Mbps link.

Is your application observing any errors while transmitting the packets in 100 Mbps configuration? 

I will check with our team and get back with on this behavior between 1G and 100M links in 3-4 working days. 

Thanks and regards,
Teja.