TDA3: How to enable AVS for TDA3x if bootloader does not support I2C at boot?

Hello Rishabh,

I shared your response with the customer and pointed the customer to E2E.

I will update you.

Hello Stan,

I am using the document, "TDA3x_SR2.0_SR1.0A_SR1.0_NDA_TRM_vN.pdf".

Checking TI CDDS, I believe this is the latest version of the TDA3x TRM.  I did not see a newer version.  vN has the statement in full.  Your statement leads me to believe I may be using an older TRM.  Won't you please clarify?

Thank you BOTH for responding to my question.

Hi, Jason,

Stan refers to the newest version of the TRM which is not yet uploaded to ti.com.

I will send you in a private mail the link where you can download it.

Regards,
Mariya

Hi All,

I see some contradictions between TRM (vO) and ap note http://www.ti.com/lit/an/slva646/slva646.pdf. .

A. Compensated parameters :

App note states :

Class 0

– This class accounts for process variations. Temperature and aging should be factored into the

voltage-margin.

TRM states:

3.1.1.3.3.1 AVS Class 0 (SmartReflex™) Voltage Control

Adaptive Voltage Scaling (AVS) Class 0 (also referred to as SmartReflex) is a procedure for lowering the

voltage on certain device power rails. AVS Class 0 attempts to normalize the power consumption across

all devices. The optimal voltage for each AVS supported rail of each device is determined after analysis in

the factory. This value is written in the device eFuse where it can be read through dedicated registers.

These registers reside in the control module.

3.1.2.4 Adaptive Voltage Scaling

AVS achieves the optimal performance/power trade-off for all devices across the technology process

spectrum. This ensures optimal power consumption for a given OPP.

3.1.2.5 Combining Power-Management Techniques

AVS must be used at boot time to adapt the voltage to the process characteristics (strong/weak) of the

device and then be used continuously to compensate temperature variations. AVS can also ensure the

maximum available application performance of the device at a given OPP.

B. When to implement  AVS:

App note:

4 Implementing AVS and DVFS:

The power-supply is programmed to power up with the nominal voltage that the processor domain

requires for the desired worst-case (weak silicon) boot-OPP. Voltage specifications for boot time are

generally provided in the processor data sheet. After booting, the processor communicates the AVSvoltage

per domain to the supply, which adjusts the output voltage accordingly. In case of a change of

operating performance point (OPP), the processor notifies the supply of a change in supply voltage, then

the supply sets the outputs to the nominal output voltages again, and finally lowers these voltages to the

appropriate AVS-levels for the new OPP.

TRM:

3.1.2.5 Combining Power-Management Techniques

AVS must be used at boot time to adapt the voltage to the process characteristics (strong/weak) of the

device and then be used continuously to compensate temperature variations. AVS can also ensure the

maximum available application performance of the device at a given OPP

***********************************************

For our use case:

We use the OPP nom which requires 1.06V at Boot-up and AVS after boot-up 0.88-1.06V.

I don't see how will be affected the internal function of the processor if will require a voltage lower then the one at Boot-up, just for power optimization.

**********************************************

In case we would use switch higher OPP: OD or HIGH... then it make sense to change before everything will run at higher frequency and require higher voltage.

Hi, Mihai Hurdugaciu (3251090),

About your A question - it was clarified in the post that "used continuously to compensate temperature variations." is removed from TRM in the latest version (vN), not yet released.

For your B question - see

Regards,

Mariya

Hi Mariya,

Ok, for A point I misunderstood , I thought that the text was added, sorry . I have the (v O) which was shared under NDA condition to us just some days and the text was there.
In parallel I received also a public version which does have the text corrected.

For Point B I think we have some confusion on the "BOOT Time":
- our SW colleagues consider BOOT time the SBL Code execution
- TI considers "BOOT time" = ROM code execution

In the post that you mentioned is discussed only the voltage value needed during the ROM code execution time end why is different.
But not when to set the AVS value -> when TDA3 should set via I2C/SPI the PMIC registers with AVS value from TDA3 register.

In our case the I2C driver is included in the "application" part not in the SBL=Bootloader in the first post.
So in the end the Question is :

It is ok if?
- during ROM code execution we have the value written in DM with condition -> BOOT (Before AVS is enabled)
- we run the SBL with the same voltage
- we start the "application SW" , set in the first moment the AVS value in the PMIC

Do you see any risk for the TDA3x integrity, lifetime, etc.?
From our side we do not have a problem with the extra power dissipation during SBL execution.

BR,
Mihai

Hi Mihai,
You are right for the boot time, it is a broad notion that can denote the time from reset release up to GUI up and running.
However, the SoC-controlled boot phase stretches only to ROM handover to SBL. SBL is the first user software to run, and therefore, for SoC, it is a boot complete. Actually it is not even known if you will be loading an OS after all. One may wish to run a software w/o an OS.

Regarding AVS:
Since there is no way to know the optimized settings of every actual silicon before power-up, therefore, there exist 'fail-safe' (BOOT) settings that will allow every single silicon to boot fine. Those settings are pre-loaded in the PMIC's OTP memory at factory and apply at power-up. Then, after SBL kicks in, it will load to the PMIC the optimized ones according to actual silicon.

"Do you see any risk for the TDA3x integrity, lifetime, etc.?"
- Yes, TI requires AVS to be enabled earliest in the code.

I personally think you will not see immediate issues. I guess you can leave things as is for now and release a software patch later when you have time (sooner is better).

Regards,
Stan

Hi ,

"As early as possible" is generic and hard to implement by engineers, so.... 

We moved the AVS command to PMIC in SBL and we have an estimation of 4s till the command will be executed.

Is tis an acceptable value?

Thank you.

Regards

Mihai

Hi Mihai,

Can you please explain how did you arrive at the value of 4 s.
AVS takes few milli-seconds.

Regards,
Rishabh