Part Number: TAS5756M
Other Parts Discussed in Thread: TAS5805
So, starting a new board development and it looks like TAS5756M may be a good fit. I've been looking through the datasheet and have a couple really basic questions that I hope to get answered.
1. The device has many DSP features that allow extensive Audio Chain customization. This is done through "HybridFlows". Choosing the configuration parameters for a "HybridFlow" is so complex that it is done through TI's proprietary "PurePat Console" software and downloaded to an expensive TI-proprietary Eval Board. Correct so far?
That's all well and good for evaluating the chip, but how does it work on my production board? How is a "HybridFlow" saved and loaded into the device on my board? Non-volatile memory within the TAS5756M and loaded on power-up? Non-volatile memory on my board and loaded over I2C by a separate processors? The TAS5756M acts as a bus master to download the "HybridFlow" from an external I2C EEPROM on my board (without an external processor)?
How is the register configuration for a chosen "HybridFlow" extracted from "PurePat Console" and used?
2. From Section 8.3.1 of the datasheet (Power-on-Reset (POR) Function), I note the following paragraph:
"The TAS5756M device has a power-on reset function. This feature resets all of the registers to their default configuration as the device is powering up. When the low-voltage power supply used to power DVDD, AVDD, and CPVDD exceeds the POR threshold, the device holds sets all of the internal registers to their default values and holds them there until it receives valid MCLK, SCLK, and LRCK/FS toggling for a period of approximately 4 ms. After the toggling period has passed, the internal reset of the registers is removed and the registers can be programmed via the I2C Control Port."
That seems like a relatively straight forward statement, but I find it hard to believe. Is it saying that the device's registers can't be configured over I2C until a valid I2S input signal (MCLK, SCLK, LRCK) is present? What would be the rational for such a design decision? It makes much more sense to me to be able to configure the device on power up with or without an I2S signal and then go from there. I certainly hope someone will tell me that my interpretation of the above paragraph is incorrect.
Thanks all.