Part Number: AM625
Other Parts Discussed in Thread: AM62A7, , AM62L, AM62P, AM6422
Tool/software:
Hi TI Experts,
I have the below query
AM62A7: How can we change the drive strength of the SPI interface
AM625: How to change the drive strength of the ethernet interface IOs
AM625: How to change the drive strength of the OSPI interface IOs
In general can i configure the drive strength for the SOC IOs or peripherals.
Hi Board designers,
Inputs related to drive strength for AM62L
Please refer below table of the processor-specific TRM for information related to drive strength (Dual-voltage IOs, For LVCMOS Buffer Type Only) or slew rate (Fixed-voltage IOs, For 1P8-LVCMOS Buffer Type Only) configuration supported:
Pad Configuration Registers
Pad Configuration Register Functional Description
The pad configuration registers are used to configure most of the device pads. Each pad configuration register is
associated only with one pad and has bits as described in Table 14-3860.
Description Of The Pad Configuration Register Bits for AM62L IO pad configuration:
Nominal impedance
Dual-voltage IO buffers
SDIO Buffer - 40Ω
LVCMOS Buffer NOM- 60Ω
LVCMOS Buffer FAST - 50 Ω
The above is valid for AM62x, AM62A, AM62P, AM64x, AM243x
Fixed voltage 1.8V IO buffers (AM62L):
1P8-LVCMOS Buffer – 50 Ω
AM62A
(4) Use of settings other than the reset value could invalidate datasheet timings.
Note:
The IO buffer output impedance is valid when the IOs are operating (operating voltage) at 1.8V or 3.3V
The IO buffer output impedance is valid when the IOs are operating withing the ROC as per the processor-specific data sheet for a given operating voltage.
Note:
We are working to enable a faster drive strength option, but there is no plan to support a reduced drive strength mode.
timeframe or ETA for the faster drive strength feature
I do not, it is currently down to alignment for an SDK release to contain the feature as this has to be supported and enabled in SW.
Regards,
Sreenivasa
Hi Board designers,
Inputs related to verifying drive strength change:
Customer is measuring signal rise/fall time as a way to confirm drive strength changes.
The drive strength register changes the output buffer source impedance, which may not have a significant impact on signal rise/fall time at the far end of the PCB trace. The bandwidth of the PCB trace can also limit the signal rise/fall times. The reflections that occur on the PCB trace can distort the signal shape. In some cases, these reflections may result in waveform shapes that are counter-intuitive or unexpected.
They may be able to observe a waveform shape difference at the source end of the signal trace that can be used to confirm the output impedance change if the PCB trace is long enough for the signal to rise before the first reflection from the far end of the PCB trace returns.
We designed in our PHY and AM64 at our customer.
The latest assessment shows that there might be some issues with our spec:
We were taking some measurements on our board where we use the AM6422 and DP83822 PHYs and I noticed some values that I was wondering if you could help me clarify.
In the AM6422 Datasheet I see the information below:
Looking at our PHY:
I attached a sample measured of RX_D1 and TX_D1 as references, but similar timings are observed on all relevant signals:
As you can see above, when it comes to the TX signals the requirements are fulfilled both for the processor and the PHY.
This is, unfortunately not the case for the Receive signals, so my questions are :
The minimum input slew rate defined for AM64x is equivalent to the input rise/fall time requirements defined for the PHY. A 20% to 80% or 80% to 20% voltage change is a voltage change that is equal to 60% of VDD. In your case, VDD is 3.3V and 60% of 3.3V is 1.98V. Changing the signal by 1.98V in 0.75ns gives a slew rate of 1.98V/0.75ns = 2.64V/ns. So, the requirements are the same for both devices and matches the signal rise/fall times defined in the RGMII standard.
Measuring the rise/fall time at the source end of an LVCMOS signal can be misleading. The voltage at the source end of the signal only steps up to a mid-supply potential until the signal has time to propagate down to the far end of the signal trace and the high impedance connection at the far end returns an in-phase reflection to the source. Therefore, measuring a 20/80 rise/fall time at the source will include 2x the PCB trace propagation delay in your measurement. The far end of the signal trace doesn't see this additional delay. I suggest you find a place to probe the RX_D1 signal near the AM64x device to get an accurate rise/fall time measurement for the RX input. Otherwise, you could subtract about 0.334ns for each inch of signal trace from the measured value at the source to get a value that is close to what is seen by the RX input. For example, you would subtract 1ns from the 1.7ns fall time measurement if you have 3 inches of PCB trace between the probe point and the RX input pin.
(+) AM62P-Q1: drive strength of EMMC I/F - Processors forum - Processors - TI E2E support forums
The SDIO and LVCMOS references from the other E2E thread was with respect to these specific IO buffer types. The IO buffer type for each device pin can be found in the BUFFER TYPE column of the Pin Attributes table in the device datasheet. The AM62Px MMC0 port uses the "eMMCPHY" buffer type rather than the SDIO buffer type. The output buffer associated with the eMMCPHY buffer type supports multiple source impedances, where it can be configured to operate with a source impedance of 33, 40, 50, or 66 ohms. However, I'm not sure if we plan to support all of these options. I'm fairly sure 50 ohms will be supported and there is a good chance 40 ohms will be supported. I will need to check and get back to you on this topic.
You are able to control the output source impedance of the AM62Px MMC0 port via the DR_TY bit field of the MMC_SSCFG_PHY_CTRL_1_REG register.
I have discussed the source impedance options with our design team, and they said customers should attempt to design their PCB to operate with the 50 ohms source impedance option since this is the recommended value defined in the eMMC standard.
Regards,
Sreenivasa
