Core clock rates and effect on high sample rates

If you have a simple question and just want an answer.
audioengr
Junior Member
Posts: 4
Joined: Fri Mar 22, 2013 5:57 pm

Core clock rates and effect on high sample rates

Post by audioengr »

I have a XS1-L1 type custom design compiled into the 48-pin XMOS chip, same number of tiles etc.  There are only a couple of changes to the reference code, including bringing out the sample rates.

When I stream sample-rates of 44.1-96, it works perfectly on Mac and PC.  When I run 176.4 or 192, it has data errors on S/PDIF output and I2S output. My DAC recognizes output from the board, but no music using S/PDIF and when I drive the DAC directly with I2S I get music but lots of crackling on music transients.  I have traced it back as far as the XMOS chip, so its not my ancillary logic. I am using a separate USB power supply to enable fewer data errors on the USB cable and I'm using a very short USB cable.

Since this design was compiled into the 48-pin chip by a third-party, I dont have much visibility into what was done.  I am designing the hardware only. I have sent the third-party emails, but he is not responsive.  Therefore, I am doing what I can myself to diagnose the problem.

I suspect that maybe the core tile reference clock is maybe too low in frequency.   I am having difficulty trying to get the JTAG debbuger working so I can simply read out the digital node PLL configuration register.

Can someone tell me what the OD, F and R registers are set at in the XS1-L1 design?

Is there any other reason why there might be marginal timings inside the 48-pin XMOS chip or between the USB chip and the XMOS chip?

I also tried changing the timing between the XMOS chip and the USB chip, giving the XMOS chip more setup time.  No effect.

Thanks,

Steve N.

 



User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Could be many things so here are some initial thoughts.. bit of  a brain dump 

Get a full diff of what has changed in the SW. The base reference design should be rock solid.. It has been designed in hundreds of times

If the data is corrupt on both SPDIF and I2S then it's obviously something further back in the system. Ie somewhere between the buffer and the host.

Is the higher sample rate problem on both mac and pc? 

I'm wondering if it is a USB error issue or device side.

what does a USB trace look like? Errors seen?

Definitely check your clocks - What is your core clock and what is the ref clock vs the clock input? These are nominally set to 500 and 100 MHz on the standard ref design. In fact if they are much different then it probably won't work.. 

I'm afraid having no visibility of the code is going to make this a bit tricky to diagnose..

User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

<quote>I only have the Binary and no source code for the XMOS design.
Is is possible to read the PLL registers in the chip using JTAG without giving XTimecomposer the source files?
Steve N.</quote>
 
There are a few ways to approach this without source (although I still strongly reccomend you get the source, or work with the design authority to solve this)
 
You can do the following:
 
xobjdump -s <myxefile.xe>
 
That will get you:
 
- The XN file. This will tell you the original frequency settings
- Elf files (second stage loader and actual node binaries)
- programinfo.txt which will give you key info, including PLL setting and ref clock divisor 
 
Alternatively, you can run this from gdb to get pll and boot info (works on single digital tile devices only):
 
    set $tap = 0
    sysreg read $tap 1 0x5
    printf "    Node id 0x%04x\n", $sysregval
 
    sysreg read $tap 1 0x6
    set $pllod = ($sysregval) >> 23 & 0x7
    set $pllf = ($sysregval) >> 8 & 0x7FF
    set $pllr = ($sysregval) >> 0 & 0x7F
    set $pllratio = ((float)$pllf+1)/2/($pllr+1)/($pllod+1)
    printf "    PLL reg 0x%08x [OD=%d+1 F=(%d+1)/2 R=%d+1]\n            ratio %f [%d/%d/%d @20/24/25 Mhz]\n",  $sysregval, $pllod, $pllf, $pllr, $pllratio, 20*$pllratio, 24 * $pllratio, 25*$pllratio
 
    sysreg read $tap 1 0x0
    set $bootmode = ( $sysregval >> 16 ) & 0xff
    printf "    BootMode : 0x%02x\n", $bootmode
 
If you are unsure how to drive gdb, just run:
 
xgdb
attach
 
then paste in the above script.
 
If you are interested to find out more about this - the full gdb script this was taken from can be found here, and works on any device:
 
https://github.com/xcore/xgdb_scripts