Hi,
According to the official configuration file,
the I2C addresses of PLL and DAC are 0x62 and 0x48, respectively.
Yet, the datasheets of them provide different information.
For Si5351, the I2C address should be 0x60 or 0x61,
as shown on Page 16 of Si5351 datasheet.
For SABRE9018Q2C, the I2C address should be 0x90 or 0x92.
I'm confused because the EVB works well under the official configuration.
Any advice? Thank you.
XK-USB-AUDIO-HPA PLL&DAC I2C addresses
-
- Junior Member
- Posts: 7
- Joined: Fri Aug 18, 2017 2:00 pm
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. Short answer, the I2C address is 0x62 for the soldered part on this PCB from XMOS.
Long answer,
1) SI5351A features an OTP option so that the device can power up and start clocking out user defined custom clock values.
2) The OTP programming details are not available to the general public and therefore the part must be programmed at the factory (Silabs).
3) It is possible for anyone to forward your preferred clock values to Silabs and they will program the OTP for you for your project. Believe the MOQ may be a full T&R but you can always ask your local Silabs rep.
4) We have done this for another project already with success using our custom clock values. XMOS has done the same and made this custom p/n available to other developers for this same project:
https://www.digikey.ca/product-detail/e ... SD&lang=en
So if you reference,
Manufacturer Part Number
SI5351A-B04486-GT
then this PLL will clock out the same clock values as you see on the XMOS PCB using the OTP state machine. The XMOS firmware is of course free to alter the power up default values using the I2C interface at anytime. Cool little part and very cost effective.
BTW - Have seen some offshore XMOS modules where they just stuff fixed clock oscillators rather than the PLL to achieve the same idea but this is assuming the clocks are then fixed. However, this fixed osc idea may be for other XMOS related IP.
Here is the full clock summary of the same custom PLL component:
https://www.silabs.com/internal-apps-ma ... dendum.pdf
If you wish to define your own custom values, download the Silabs Clock Builder tool (free download) and proceed away. Inside this tool you can generate the required formatted file for the Silabs factory to program your custom part.
Not sure on the DAC I2C address as we are not (yet) audio developers.
If you should consider to design your own variation of this design, do post the relevant portions for a review before starting any production. Keep in mind that the flash firmware must be programmed out of circuit or pre-programmed with QSPI bit enabled before you can use with this XMOS CPU. There is no support over USB to program the flash during first time power up. Once the firmware is present, you can proceed to upgrade over USB.
Long answer,
1) SI5351A features an OTP option so that the device can power up and start clocking out user defined custom clock values.
2) The OTP programming details are not available to the general public and therefore the part must be programmed at the factory (Silabs).
3) It is possible for anyone to forward your preferred clock values to Silabs and they will program the OTP for you for your project. Believe the MOQ may be a full T&R but you can always ask your local Silabs rep.
4) We have done this for another project already with success using our custom clock values. XMOS has done the same and made this custom p/n available to other developers for this same project:
https://www.digikey.ca/product-detail/e ... SD&lang=en
So if you reference,
Manufacturer Part Number
SI5351A-B04486-GT
then this PLL will clock out the same clock values as you see on the XMOS PCB using the OTP state machine. The XMOS firmware is of course free to alter the power up default values using the I2C interface at anytime. Cool little part and very cost effective.
BTW - Have seen some offshore XMOS modules where they just stuff fixed clock oscillators rather than the PLL to achieve the same idea but this is assuming the clocks are then fixed. However, this fixed osc idea may be for other XMOS related IP.
Here is the full clock summary of the same custom PLL component:
https://www.silabs.com/internal-apps-ma ... dendum.pdf
If you wish to define your own custom values, download the Silabs Clock Builder tool (free download) and proceed away. Inside this tool you can generate the required formatted file for the Silabs factory to program your custom part.
Not sure on the DAC I2C address as we are not (yet) audio developers.
If you should consider to design your own variation of this design, do post the relevant portions for a review before starting any production. Keep in mind that the flash firmware must be programmed out of circuit or pre-programmed with QSPI bit enabled before you can use with this XMOS CPU. There is no support over USB to program the flash during first time power up. Once the firmware is present, you can proceed to upgrade over USB.
-
- Junior Member
- Posts: 7
- Joined: Fri Aug 18, 2017 2:00 pm
Thank you.
And
How did you write the DAC part of the EVB configuration file without its I2C address?
And
The documents shows that xCORE-AUDIO Configuration Utility was published by XMOS.mon2 wrote: Not sure on the DAC I2C address as we are not (yet) audio developers.
How did you write the DAC part of the EVB configuration file without its I2C address?
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. Sorry for the confusion. We do not work for XMOS. Our company is primarily a PC peripheral / add-on designer and manufacturer.
-
- Junior Member
- Posts: 7
- Joined: Fri Aug 18, 2017 2:00 pm
Thank you all the same.mon2 wrote:Hi. Sorry for the confusion. We do not work for XMOS. Our company is primarily a PC peripheral / add-on designer and manufacturer.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. The confusion on the I2C addressing is due to the reference used by ESS vs. XMOS. In the end, both result in the same result so it works correctly as you noted.
1) The SABRE9018 DAC datasheet shows that there is an ADDR pin for the I2C definition. ESS is showing the I2C address inside a 8 bit width as follows:
2) XMOS I2C master IP requires the definition of the I2C slave in a 7 bit format. So the XMOS user must take the hardware I2C address of:
0x90 (since ADDR = 0 in the hardware schematic) = 1001 0000 and shift to the right by 1 bit
1001 0000 >> 1 = 0100 1000 = 0x48
The XMOS IP will take this 7 bit value (shift to the left by 1 bit) and append (logical OR) the R/W LSB bit as per the I2C spec and actually spit out 8 bit values (ie. 0x90 for I2C Write or 0x91 for I2C READ).
An I2C bus analyzer will dissect this 8 bit value to offer the 7 bit address of 0x48 and show a W if LSB is 0; R if LSB is 1.
Summary:
a) The 7 bit I2C address of this DAC is truly 0x48 if ADDR = 0. As used by XMOS for this specific audio design. If ADDR = 0 then ESS states I2C address in 8 bit (0x90) is 1001 0000 but XMOS wants 7 bit value only so right shift by 1 = 0100 1000 = 0x48. The XMOS IP will convert this passed 7 bit address back to an 8 bit format with the R/W embedded to chat with the target I2C device.
b) The 7 bit I2C address of this DAC will be 0x49 if ADDR = 1. If ADDR = 1 then ESS states I2C address in 8 bit (0x92) is 1001 0010 but XMOS wants 7 bit value only so right shift by 1 = 0100 1001 = 0x49. The XMOS IP will convert this passed 7 bit address back to an 8 bit format with the R/W embedded to chat with the target I2C device.
I think this website explains the concept well:
https://www.ez-robot.com/Community/Foru ... readId=322
1) The SABRE9018 DAC datasheet shows that there is an ADDR pin for the I2C definition. ESS is showing the I2C address inside a 8 bit width as follows:
2) XMOS I2C master IP requires the definition of the I2C slave in a 7 bit format. So the XMOS user must take the hardware I2C address of:
0x90 (since ADDR = 0 in the hardware schematic) = 1001 0000 and shift to the right by 1 bit
1001 0000 >> 1 = 0100 1000 = 0x48
The XMOS IP will take this 7 bit value (shift to the left by 1 bit) and append (logical OR) the R/W LSB bit as per the I2C spec and actually spit out 8 bit values (ie. 0x90 for I2C Write or 0x91 for I2C READ).
An I2C bus analyzer will dissect this 8 bit value to offer the 7 bit address of 0x48 and show a W if LSB is 0; R if LSB is 1.
Summary:
a) The 7 bit I2C address of this DAC is truly 0x48 if ADDR = 0. As used by XMOS for this specific audio design. If ADDR = 0 then ESS states I2C address in 8 bit (0x90) is 1001 0000 but XMOS wants 7 bit value only so right shift by 1 = 0100 1000 = 0x48. The XMOS IP will convert this passed 7 bit address back to an 8 bit format with the R/W embedded to chat with the target I2C device.
b) The 7 bit I2C address of this DAC will be 0x49 if ADDR = 1. If ADDR = 1 then ESS states I2C address in 8 bit (0x92) is 1001 0010 but XMOS wants 7 bit value only so right shift by 1 = 0100 1001 = 0x49. The XMOS IP will convert this passed 7 bit address back to an 8 bit format with the R/W embedded to chat with the target I2C device.
I think this website explains the concept well:
https://www.ez-robot.com/Community/Foru ... readId=322
-
- Junior Member
- Posts: 7
- Joined: Fri Aug 18, 2017 2:00 pm
Thank you so much!mon2 wrote:Hi. The confusion on the I2C addressing is due to the reference used by ESS vs. XMOS. In the end, both result in the same result so it works correctly as you noted.